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>
If the presentation time isn't known, e.g. if the monitor is virtual and
the actual presentation happens far away, the presentation time we
actually received tends to be the time a frame was presented to the next
layer, meaning practically immediately after painting.
When scheduling another update after that, don't assume that if the next
calculated update is not the immediate next update, schedule an update
sooner, as that will in such cases always be true, meaning we ended up
busy looping with constant frame updates being scheduled.
Fix this by only triggering that logic if the last presentation time was
actually vsync:ed.
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>
Don't expose its headers, remove all getters, and move the rest to
cogl-output-private.h. Next commits will clean it up even more, but
for now, just make it private.
This will help next commits remove CoglOutput.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3792>
When cloning an actor we were applying a global scale to it, based on
the size of the clone itself and of the cloned actor.
This implied that the transformed size of the clone was not the one that
was set, but it was taking taking in account the actor scaling too.
So in practice we were scaling it twice.
While this had no visual implications it indeed was causing troubles
when a ClutterClone was reactive because in such case only the scaled
area of the scaled clone was considered reactive.
Assume you had an actor of 100x100 pixels, scaling it to a clone of
50x50 pixels:
- The scale applied to the clone was 0.5
- The transformed size of the clone was: 25x25 pixels
- The clone was reactive only in that sub-area
To avoid this, never touch the clone transformation matrix, but only
transform it at paint time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2959>
