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
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
If a MetaWindow's 'appears-focused' state changed to true, but the
window did not have pointer focus, the constraint did not enable. Thus,
make it possible for the user to also click the window to enable it.
https://bugzilla.gnome.org/show_bug.cgi?id=762661
Instead of relying on the keyboard focus surface, use the
'appears-focused' state of the corresponding MetaWindow to determine if
a constraint should enable or not.
https://bugzilla.gnome.org/show_bug.cgi?id=762661
Instead of having MetaWindowWayland having hooks into pointer
constraints subsystem, have the pointer constraints subsystem listen
for the signal itself and enable/disable itself.
https://bugzilla.gnome.org/show_bug.cgi?id=762661
Instead of having a very large region represent an infinitely large
region, use NULL, and use the calculated input region from the
MetaWaylandSurface if the constraint region was not set.
https://bugzilla.gnome.org/show_bug.cgi?id=762661
The when surface->input_region is NULL, it should be interpreted as the
whole surface region. If not, the effective input region is the
intersection of the buffer region and the input region set by
wl_surface.set_input_region. Add
meta_wayland_surface_calculate_input_region() that does this
calculation.
https://bugzilla.gnome.org/show_bug.cgi?id=762661
The constraint may be destroyed before the client destroyes the
protocol object, for example if a oneshot constraint was disabled by
alt-tab. Therefore we need to NULL check the constraint in request
handlers and ignore any requests to defunct objects.
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
