It is often useful to identify the client process that created
a particular window, however the existing meta_window_get_pid()
method relies on _NET_WM_PID, which is only available on X11 and
depends on applications to set it correctly (which may not even
be possible when the app runs in its own PID namespace as Flatpak
apps do). So add a get_client_pid() method that uses windowing
system facilities to resolve the PID associated with a particular
window.
https://bugzilla.gnome.org/show_bug.cgi?id=772613
Previously the focus was reset implicitly by a memset() on the whole
MetaWaylandPointer struct. When MetaWaylandPointer was turned into a
GObject, this was not possible any more, and the focus was not updated
properly.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
Going through the global mode pool and then checking if the mode is
available for a given output is pointless work since we can look at
the output's available modes directly.
This implicitly changes how we choose the default mode since, instead
of relying on the sort order of the global modes array, we now rely on
the sort order of the output modes array. Still not ideal, but at
least it makes more sense since the global array is essentially
unsorted.
https://bugzilla.gnome.org/show_bug.cgi?id=772176
This isn't technically needed and, in fact, makes us default to
interlaced modes in some cases which isn't desirable.
Note that X doesn't account for these flags either for its mode
refresh rates.
https://bugzilla.gnome.org/show_bug.cgi?id=772176
As the m format specifier doesn't consume any arguments, the number
of varargs currently doesn't match the number of specifiers; the
failed transform may be relevant, so include it in the message
instead of removing the excess argument.
There may be other windows managing selection whose events are seen in
our GDK event filter, like st-clipboard in gnome-shell, we should in
that case not interfere on Selection/SelectionRequest events that are
not meant for us.
This fixes an odd feedback loop where requesting clipboard contents from
wayland results in a XConvertRequest call and a SelectionRequest event
that is interpreted by mutter as a request from another X11 client, so
the current data source is poked for content, which happens to be the
X11 bridge, which does a XConvertRequest to get contents... This is only
broken after the many nested async operations create enough pipes and
cancellables to run out of fds.
Adding checks to ensure only events meant to our "selection owner"
window are managed prevent this unintended loop to happen in the first
place.
https://bugzilla.gnome.org/show_bug.cgi?id=760745
backends/meta-input-settings.c:1245:27: error: format '%lx' expects
argument of type 'long unsigned int', but argument 3 has type 'guint64
{aka long long unsigned int}' [-Werror=format=]
Those will be unseen by g-s-d/g-c-c, so no settings will be written on
disk for those. Still, look up an ID correctly in this case instead of
crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=771628
When we mess with a window actor's visibility from the shell side
(yes, I know :-( ), we should at least restore the proper visibility
when we're done with it ...
https://bugzilla.gnome.org/show_bug.cgi?id=771536
A xdg_popup, when active, always has a parent surface. However, a popup
created may immediately become invalid, for example when it is not
granted a grab, in which case it won't be assigned a parent since it
will never be mapped.
This case needs to be handled elsewhere, as one cannot assume a
MetaWaylandXdgPoup that is processed (via wl_surface commit handling
etc) will have a parent_surface.
https://bugzilla.gnome.org/show_bug.cgi?id=771495
If a X11 client would initiate a Xdnd session after it had lost pointer
focus (for example when the Xdnd event starting the drag happens after
the implicit pointer grab is already broken due to the button being
released), just end the drag operation instead of dereferencing the
non-existing focus surface.
Also avoid using a native Wayland surface as a drag origin, as that can
never happen, but allow any arbitrary Xwayland client, since there is
no way to find out the actual drag origin.
https://bugzilla.gnome.org/show_bug.cgi?id=770940
We cannot check 'has-target' or 'has-seat' when verifying a
wl_data_offer.finish request is valid or not, since the source may have
effected 'has-target' or whether theh source has a seat or not when the
finish request was already on the wire.
Instead of checking against the source state, keep track whether the
required operations has been done on the offer in question (i.e.
whether an action has been sent, or a mime type been accepted).
This fixes incorrectly raised error when dragging from gtk+'s testdnd
via Xwayland onto gtk+'s testdnd using Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=770937
Since wl_surface.set_buffer_transform() is not supported, until it is
added, pretend outputs are never transformed, so that clients are less
likely to attach pre-transformed buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=770672
Also maybe remove a constraint when the pointer focus changes. This is
needed because when Xwayland has a constraint focus may change, the
constraint object will not receive a 'appears-focused' event on its
window since it never changed.
This happens for example when an override-redirect window (which never
appears focused) holds the constraint, and alt-tab happens. In this case
focus changes, but from the constraint's point of view, none of the
windows it knows about changed its focus appearance.
https://bugzilla.gnome.org/show_bug.cgi?id=771345
Instead of initializing the default grab when the device class is
enabled, initialize it on object initialization. This way other device
classes can still grab the pointer, as if there was one. This may be
useful for example if a touch grab is active and a mouse is connected.
This also makes it possible for popup grabs, which currently use a
pointer grab for controlling, to be triggered by touch devices, while
still holding an active pointer grab.
https://bugzilla.gnome.org/show_bug.cgi?id=771305
Make the device <-> seat association permanent, and move it into
MetaWaylandInputDevice. A device will never be disassociated with a
seat, so there is no point in unsetting it.
https://bugzilla.gnome.org/show_bug.cgi?id=771305
Add a new object class, MetaWaylandInputDevice, and make all device
classes (pointer, keyboard, touch) inherit it. In the future common
functionality may be placed there.
https://bugzilla.gnome.org/show_bug.cgi?id=771305
Meant to replace explicitly checking whether a
MetaWaylandPointer/MetaWaylandKeyboard/MetaWaylandTouch has a seat or
not to determine whether they are supposed to be active or not.
https://bugzilla.gnome.org/show_bug.cgi?id=771305
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
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
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
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
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
If cogl fails to create a texture from the client's given buffer,
mutter would raise a fatal error and terminate.
As a result, a broken client might kill gnome-shell/mutter and take the
entire Wayland session with it.
Instead of raising a fatal error in this case, log the cogl error
message and send the client an OOM error, so mutter/gnome-shell can
survive an unsupported buffer size.
https://bugzilla.gnome.org/show_bug.cgi?id=770387
