This is needed to make the wayland backend react to configuration
changes until gnome-control-center is updated to use the
gsettings-desktop-schemas settings.
https://bugzilla.gnome.org/show_bug.cgi?id=771315
Some output devices only advertise their preferred mode even though
they're able to display others too. This means we can include some
common modes in each output's supported list.
This is particularly important for mirroring, since we can only mirror
outputs which are using the same resolution.
https://bugzilla.gnome.org/show_bug.cgi?id=744544
Since Xwayland surface constraints might need to enable not only
because the constrained window appears focused, add a pointer focus
listener and try constrain whenever the pointer focus changes. It's
still required that a Xwayland window is focused to activate.
https://bugzilla.gnome.org/show_bug.cgi?id=771050
Xwayland surfaces are special, because there is no reliable way to
associate a window with its corresponding "application window" (the one
which was given focus). Many games that require pointer warping and
confining pointer grabs may for example create override redirect windows
and make that window receive input even though it will never be the
focus window.
Therefore, the requirements for enabling a constraint for a wl_surface
from Xwayland needs to be relaxed in order. This commit changes
Xwayland wl_surfaces to not require being focused to be enabled; it'll
be enabled as long as any X11 window is the one with focus.
https://bugzilla.gnome.org/show_bug.cgi?id=771050
Require pointer focus to enable, otherwise we can't guarantee it has
entered the surface, as the focus may have been given to a subsurface,
override-redirect or other sub window covering the surface that was
requested to have o pointer constraint.
https://bugzilla.gnome.org/show_bug.cgi?id=771050
Add a signal that is emitted when the pointer focus surface of the
pointer device changes. This will later be used by the pointer
constraints to maybe enable pointer constraints when a surface receives
pointer focus.
https://bugzilla.gnome.org/show_bug.cgi?id=771050
For Xwayland, a newly created wl_surface and X11 Window pair may not be
immediately associated, but Xwayland may still request a pointer
constraint on some of its wl_surface's. Handle the situation by
postponing maybe enabling the constraint until the window and surface
has been associated.
https://bugzilla.gnome.org/show_bug.cgi?id=771050
Move the MetaWaylandSurface::destroy signal before starting the actual
destruction, in wl_surface_destructor, so that all fields (e.g. surface
role) are intact when the listeners are invoked.
https://bugzilla.gnome.org/show_bug.cgi?id=771050
When the Xwayland wl_surface is created, it may not yet be possible to
associate it with the corresponding X11 Window. Add a signal to the
Xwayland role to communicate with any interested parties.
https://bugzilla.gnome.org/show_bug.cgi?id=771050
Clutter discards any motion event if next event happens to also be a
motion event. This is problematic when the motion event carries
relative motion deltas, since the information about them is completely
lost.
Until we have moved away made the stage stop discarding motion events,
lets work around the issue by compressing them, effectively adding
multiple relative motion deltas together, would one be discarded.
https://bugzilla.gnome.org/show_bug.cgi?id=771049
If a client would attach a buffer to a surface, commit, destroy the
buffer and then later set the surface as a cursor, there will be no
wl_buffer available to be used by the cursor role. Instead of
dereferencing the non-existing wl_buffer resource, handle this situation
by logging a warning and treating a prematurely destroyd wl_buffer as if
no buffer had been attached.
https://bugzilla.gnome.org/show_bug.cgi?id=770992
Not having a surface actor would cause the window actor state to be
considered frozen, thus causing various state (such as geometry, shape
etc) synchronization to be delayed until thawed. If the window actor
was "thawed" due to having a surface set, not all state would be
properly synchronized, causing the thawed window actor to be displayed
incorrectly.
This patch fixes this by putting state synchronization after thawing in
a common function, calling it both from frozen count decreasing and
surface setting.
This fixes for example misplaced menus in Steam.
https://bugzilla.gnome.org/show_bug.cgi?id=770991
The rectangle passed to capture_view() is in stage coordinate space;
thus, to translate to framebuffer coordinate space, the origin need to
be translated by the view layout position.
This fixes capturing views not at position (0, 0).
https://bugzilla.gnome.org/show_bug.cgi?id=770127
Implement min/max size request from xdg-shell-v6 and plug it into the
existing code so that windows with fixed size cannot be tiled/maximized
in Wayland just like in X11.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=770226
The seat capability updating is synchronous, but input events are
asynchronous (first queued then emitted). This means we may end up in a
situation where we from libinput first may receive a key event,
immediately followed by a device-removed event. Clutter will first
queue the key event, then remove the device, immediately triggering the
seat capability removal.
Later, when the clutter stage processes the queued events, the
previously queued key event will be processed, eventually making it
into MetaWaylandSeat. Before this patch, MetaWaylandSeat would still
forward the key event to MetaWaylandKeyboard, even though it had
'released' it. Doing this would cause referencing potentially freed
memory, such as the xkb state that was unreferenced when the seat
removed the capability.
In order to avoid processing these lingering events, for now, just drop
them on the floor if the capability has been removed.
Eventually, the event queuing etc needs to be redesigned to work better
when used in a Wayland compositor, but for now at least don't access
freed memory.
https://bugzilla.gnome.org/show_bug.cgi?id=770727
When a modal transient is unmanaging, most likely the parent of the
modal transient should be focused.
In Wayland, a MetaWindow is created when a shell surface role (like
xdg_toplevel) is created, but a window cannot be shown until a buffer
is attached. If a client would create two modal transients and make
them both have the same parent, but only one get a buffer attached
(i.e. shown), when unmanaging the modal transient that was showing,
when finding a new focus candidate, the stacking code will ignore the
not-to-be-shown buffer-less modal transient when finding a good
candidate for focusing. In the case described here, this means it will
find the parent of the unmanaging modal transient.
This newly chosen candidate will then be passed to meta_window_focus();
meta_window_focus() will then try to find any modal transient to focus
instead, will find the one without any buffer, then fail to focus it
because it cannot be mapped, thus making meta_window_focus() not focus
anything. Since meta_window_focus() didn't change any focus state, the
assert in meta_window_unmanage() checking that the unmanaging window
isn't focused anymore will be hit, causing mutter to abort.
For now, fix this by checking whether the modal transient can actually
be focused in meta_window_focus(). For X11 client windows, a window
will be defined to be focusable always, but for Wayland client windows,
a window will be determined focusable only if it has a buffer attached.
In the future, we should probably do a more thorough refactorization of
focus handling to get rid of any X11 - Wayland differences.
https://bugzilla.gnome.org/show_bug.cgi?id=757568
We may be assigned multiple times, if the surface is assigned to be a
cursor surface multiple times. Each time e.g. wl_pointer.set_cursor is
called, we'll be assigned.
While the role object exists, we'll handle buffer use count even when
we are not actively assigned, thus we should only handle the initial
assignment use count bump when constructing, so that we don't increase
it when reassigned, where the wl_resource may already have been
released.
https://bugzilla.gnome.org/show_bug.cgi?id=770402
For backend handled cursors, if nothing else changes on the clutter
stage, we end up not sending out frame callbacks since clutter doesn't
draw a new frame.
To fix this, we'll keep cursor surfaces' frame callbacks separate from
other surfaces' and trigger them from the new
MetaCursorRenderer::cursor-painted signal which handles both software
and hardware cursors.
https://bugzilla.gnome.org/show_bug.cgi?id=749913
This signal allows interested parties to be notified of a new cursor
frame being painted regardless of whether it's being painted by the
backend directly or if it's a software rendered cursor frame handled
by clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=749913
Instead of hiding stage views enablement behind MUTTER_STAGE_VIEWS=1,
default to enable it, while making it possible to disable using
MUTTER_STAGE_VIEWS=0 instead.
https://bugzilla.gnome.org/show_bug.cgi?id=770366
Absolute pointer events used the X coordinate as both X and Y. This
caused the pointer cursor to be moved incorrectly for absolute pointer
devices, commonly used in virtual machines.
https://bugzilla.gnome.org/show_bug.cgi?id=770557
Even without a compositor grab, key events may still be expected to
be processed by the compositor and not applications, for instance
when using ctrl-alt-tab to keynav in the top bar. On X11, focus is
moved to the stage window in that case, so that events are processed
before they are dispatched by the window manager. On wayland, we need
to handle this case ourselves, so make sure to not pass key events to
wayland in that case, and move the key focus back to the stage when
appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=758167
The WL_bind_wayland_display spec says that EGL images should be created
using EGL_WAYLAND_BUFFER_WL as the target and a NULL context. Mesa
seems to be lenient and accept any context, however some other stacks
aren't so forgiving and fail if anything apart from EGL_NO_CONTEXT is
used.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=769731
Switch to the output naming logic used by the X server's modesetting
driver which, in particular, uses drmModeConnector's connector_type_id
instead of connector_id.
The kernel generates new connector_id's every time there are changes
which means we can't identify the same monitor on the same connector
after an hardware hotplug. Switching to connector_type_id fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=770338
