The min distance to the right/bottom edge depends on Wayland concepts
(wl_fixed_t) and eventually geometry scale. Move the logic the Wayland
side of the pointer constraints machinery to avoid the backend trying to
figure this out without the proper data.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2460>
Commit b12c92e206 ("wayland: Add MetaWaylandSurface::geometry-changed signal")
Added a "geometry-changed" signal on MetaWaylandSurface, but the matching
changes to src/wayland/meta-pointer-confinement-wayland.c made it listen
for geometry-changed on the surface-actor instead of on the surface itself,
leading to errors like these:
gnome-shell[37805]: ../gobject/gsignal.c:2429: signal 'geometry-changed' is invalid for instance '0x5653aa7cfe50' of type 'MetaSurfaceActorWayland'
This commit fixes this.
Fixes: b12c92e206 ("wayland: Add MetaWaylandSurface::geometry-changed signal")
https://gitlab.gnome.org/GNOME/mutter/merge_requests/751
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
In the unlikely case that a surface is moved by the compositor while
holding a pointer confinement, we also need to update the pointer
position when the surface actor gets moved.
https://bugzilla.gnome.org/show_bug.cgi?id=782344
This patch adds support for confinement regions that are more complex
than a single rectangle. It relies on details about cairo regions not
explicitly in the API in order to generate the outer border of the
region.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
The wp_pointer_constraints protocol is a protocol which enables clients
to manipulate the behavior of the pointer cursor associated with a seat.
Currently available constraints are locking the pointer to a static
position, and confining the pointer to a given region.
Currently locking is fully implemented, and confining is implemented for
rectangular confinement regions.
What else is lacking is less troublesome semantics for enabling the lock
or confinement; currently the only requirement implemented is that the
window that appears focused is the one that may aquire the lock.
This means that a pointer could be 'stolen' by creating a new window that
receives active focus, or when using focus-follows-mouse, a pointer
passes a window that has requested a lock. This semantics can be changed
and the protocol itself allows any semantics as seems fit.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
