Showing the stage always results in an initial update being queued. If the
virtual input events from the test ends up being dispatched after that, the
`wait_for_update()` checks gets out of sync, as the first update ended up
waiting for the initial update, not the one from the input event.
Fix the gesture test by adding another call to `wait_stage_updated()` right
after `clutter_actor_show()`.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3521
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3795>
Allow a screen cast stream source to say that nothing changed in terms
of cursor metadata, and treat this together with a cursor-only frame as
we not recording anything.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3803>
We're not doing anything significant in the KMS thread anyway, so don't
make it a kernel thread, and don't ask to be real time scheduled (which
we wouldn't be anyway, but for clarity).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3805>
Don't try to find the card, and then the render node from it, just ask
udev to list the render nodes directly. This avoids running into
permission errors when the user cannot open /dev/dri/card* even without
mode setting capabilities.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3805>
By turning a macro that exists in the codebase to a proper
function so that gnome-shell could make use of it as well
instead of using a region for it contains_point api...
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3801>
And also "completion" time to measure when the commit returned.
This is structured so as to measure all timestamps first before logging
anything. That way our results shouldn't be (don't seem to be) affected
by the logging itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3265>
While it should not be expected that we pick the pointer into a
MetaSurfaceActor that is disembodied of its MetaWaylandSurface/MetaWindow,
the paths where this should be enforced are somewhat scattered.
So account for the situation in picking code, and prefer a NULL surface
over a crash. This operates on the assumption that this inconsistent state
where Mutter didn't know better to pick a correct surface actor will be fixed
by later crossing events resolving the intermediate state, and that no
other input events will be received meanwhile.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3393
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3729>
When unmapping a subsurface, it does lose early its connection to the
parent surface. This is however a deciding factor in determining whether
the surface (role) has a window.
Make the subsurface actor unreactive if its connection to the parent
MetaWindow was severed, since it should not be eligible for picking anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3729>
These actors are expected to be destroyed along with their surface, this
however happens later in the process, so there is a moment where actors
are eligible for picking, but do not have a surface anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3729>
Prior to the grabs/focus rework in !3420, Wayland grabs were handled
separately from ClutterGrabs. This required explicitly checking for
ClutterGrabs as those were expected to prevent events from reaching
Wayland clients.
Now after !3420, Wayland client grabs also result in ClutterGrabs, which
means that this check causes input events for popups with grabs to not
get sent to ibus anymore. Instead the events are getting sent to the
client directly, which results no ibus support in popups (unless the
client handles that itself by using a different GTK_IM_MODULE).
However due to the changes from !3420 checking for ClutterGrabs is also
no longer necessary and the meta_wayland_text_input_update() focus check
is now sufficient to only forward events to ibus, when the focus is
actually on a Wayland client. So to fix this we can simply remove the
check.
Fixes: 2a584a8f0 ("wayland: Make use of Wayland event grabbing mechanism")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3502
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3787>
Reads exposed size hints for the given cursor plane. Chooses nearest
minimum cursor size out of the hints with respect to the user chosen
cursor size from the UI. Allocates optimized Hardare cursor size,
hence drm buffer
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3165>
Instead use an abstract "logical monitor id" that is generated from the
logical monitor. Instead of using low level numbers from the mode
setting devices, use either data from the EDID, or the connector, if the
EDID is not useful.
This should help with windows remembering monitor positions when the
same monitor reappears but with another mode setting device ID.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3753>
Replace the sync_focus() calls with a set_focus() do-it function taking
a surface. This is in line with the rest of the things that happen at
the default MetaWaylandEventInterface.focus implementation, and will
make these correctly observe the presence of grabs, since
meta_wayland_seat_get_input_focus() will return the would-be focus
in these cases.
This change makes the "focused" client selection truly
in sync with the keyboard focus.
Fixes: 5ca10c31d1 ("wayland: Follow seat's input focus client for clipboard selections")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3490
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3789>
Replace the sync_focus() calls with a set_focus() do-it function taking
a surface. This is in line with the rest of the things that happen at
the default MetaWaylandEventInterface.focus implementation, and will
make these correctly observe the presence of grabs, since
meta_wayland_seat_get_input_focus() will return the would-be focus
in these cases.
This change makes the "focused" client selection truly
in sync with the keyboard focus.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3498
Fixes: 9bdb00c459 ("wayland: Follow seat's input focus client for primary selections")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3789>
We were leaking the color profile path keys but also it wasn't clear how
the ownership was passed to the new hash-table, so let's just remove it
from the pending hash table and add it to the new one including the
expected reference.
This is safe because we were still adding a temporary extra ref to the
profile
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3788>
The cursor was following the "current" surface (i.e. the logical
focus, unaffected by e.g. grabs), so MetaWaylandPointer was always
providing window cursors, just so the MetaCursorRenderer would maybe
discard them and show the compositor cursor instead. E.g. in the
presence of grabs.
This clear barrier between grabs being compositor business deserving
a compositor cursor, and non-grabs being client business turned a bit
blurrier in grabs-pt5 where "client" things like popups and DnD would
also involve grabs. The fixes in that regard in the branch went on
the lenient side, introducing situations where grabs do exist but we
are preferring client-side cursors anyways.
Fix this by making MetaWaylandPointer aware of grabs at the time of
updating the client-side cursor, by following the "focus" surface
(i.e. the effective focus, affected by grabs outside of MetaWaylandInput).
The focus surface and cursor will be updated on focus changes, also
induced by grab changes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3460
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3736>
In some cases, reparenting a window with its frame may fail; this seems
to happen especially during initialization of a window that may be
unmapped and re-mapped quickly and multiple times.
If this happens, we're never going to receive a remove event on the
stack tracker and so we may end up adding it twice to the list of the
windows to synchronize with the compositor, breaking its assumption that
the stack list is unique, and eventually leading to a crash because we
do not end up removing all the instances of a window on its destruction.
In particular we may end up in this situation:
Syncing Window 10485927: 0x555558863540 (actual xid is 10485927),
user time is 10485928 frame is 0x5555588715c0, frame xid 6291591
Syncing Window 14680081: 0x5555588664b0 (actual xid is 14680081),
user time is 14680082 frame is 0x555558871d80, frame xid 6291595
Syncing Window 6291460: 0x55555796dc80 (actual xid is 10485763),
user time is 10485764 frame is 0x555557a6f630, frame xid 6291460
Syncing Window 6291465: 0x555557a68af0 (actual xid is 14680067),
user time is 14680068 frame is 0x555557a73e80, frame xid 6291465
Syncing Window 6291509: 0x555557f9d830 (actual xid is 8388623),
user time is 0 frame is 0x555557fac780, frame xid 6291509
Syncing Window 6291586: 0x5555586e1690 (actual xid is 4194363),
user time is 0 frame is 0x55555886e550, frame xid 6291586
Syncing Window 6291591: 0x555558863540 (actual xid is 10485927),
user time is 10485928 frame is 0x5555588715c0, frame xid 6291591
Where the same meta window 0x555558863540 is added twice because that's
both mapped by the window itself (10485927) and by its frame (6291591).
This happens because for historical reasons the xids hash table managed
by the x11-display maps both the X11 windows, their frames and their
user time windows as the meta-window, and so if we don't filter out them
properly we end up duplicating the entries in the compositor list.
Such duplicates finally end up making mutter to crash in
meta_compositor_sync_stack() because we could end up trying to access
to an invalid window, given its actor has been destroyed but not all the
instances have been removed from the compositor windows list:
0x00007ffff71059 in meta_compositor_sync_stack (compositor=0x555555b8,
stack=0x555558701b80) at ../../mutter/src/compositor/compositor.c:773
773 if ((old_window->hidden || old_window->unmanaging) &&
(gdb) print old_window
$1 = (MetaWindow *) 0x0
So, in order to prevent this, check that XReparentWindow does not fail,
and in case of failure, reset the window state to the one it had before
we failed and more importantly, remove the association between the frame
X11 window and the MetaWindow, since this is not true anymore and so
that at the next stack synchronization there won't be any meta window
associated to that frame XID (unless there aren't further stack changes
impacting on that). Without this we would have instead waited for the
remove event that we predicted, but that could never happen because no
ReparentNotify is emitted in such case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3732>
Since we listen the X events in the same thread, and they are delivered
through the main loop, there's not any need to set the frame details on
windows before the reparent operation, because such action could fail.
So move the code order, as preparation for handling the error.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3732>
