[RFC xwayland] Pointer warp emulation

[Peter Hutterer]

On Wed, Apr 13, 2016 at 06:07:51PM +0800, Jonas Ådahl wrote:
> With Wayland, the X server is no longer in control of the pointer
> position, and as such, clients warping the pointer has no effect. This
> causes many applications (mostly games) to fail to function properly, as
> they depend on the warp requests to actually take effect. The same can
> be said about pointer grabs with window confinement.
> 
> A way to make it possible to allow these applications to behave as
> expected is to introduce the concept of "pointer warp emulation".
> 
> I have implemented such a solution, which can be found here:
> https://github.com/jadahl/xserver/commits/wip/xwayland-pointer-warp

I had a look through these patches and nothing sticks out in a bad way. The
only issue (and we discussed this over IRC already) is that we shouldn't
drop the abs min/max ranges for the device, adding a separate relative-only
device is better here.

> It currently only works on mutter (explained further below), but should
> work with weston given by making some (minor) equivalent changes there.
> For reference, the mutter branch can be found here:
> https://github.com/jadahl/mutter/commits/wip/xwayland-pointer-warps
> 
> I have so far mostly tested with three applications (games): OpenTTD,
> Half Life 2, and Trine 1, which all seem to work fine with the current
> branch.
> 
> With pointer warp emulation, a client warping the pointer is translated
> into Xwayland using of the relative pointer[0] and pointer
> constraints[1] Wayland protocols, while faking the pointer position
> exposed to the rest of the X server.
> 
> When the emulator is enabled, the actual pointer position and the
> pointer position exposed to Xwayland may be different.
> 
> There are a few problems to solve here:
> 
> 1) when to enable a pointer warp emulator
> 2) when to disable a pointer warp emulator
> 3) when to enable a pointer lock
> 4) when to disable a pointer lock
> 
> Problem 3) needs attention in both Xwayland and in the compositor, but
> the rest can be partly solved completely in Xwayland.
> 
> As for problem 1) and 2), in my implementation I enable the emulator
> once the pointer is warped, but given that the pointer cursor and the exposed
> pointer position may be different, only as long as the pointer sprite is
> already hidden. The emulator is disabled once the sprite is made visible
> again.
> 
> As for problem 3), in the compositor I prototyped this with (mutter), I
> had to relax the requirements for enabling a pointer lock. For regular
> Wayland clients, a lock was only enabled if its surface was active/in
> focus. This was not possible for X11 clients, as often the surface that
> was the target of the warp happened to be an override-redirect window,
> which never will have such a state. So for X11 clients the requirements
> had to be relaxed, and the responsibility of behaving responsibly had to
> be partly moved to Xwayland.
> 
> In order to make Xwayland behave more responsibly regarding problem 3),
> some requirements were added in order to trigger a pointer lock. The
> requirements more or less tries to mimic the situations where the window
> would receive input events. For example the current implementation looks
> at the current grab, pointer focus and warp destination, etc to figure
> out whether locking is reasonable.
> 
> As for problem 4), in order to gracefully give back pointer control to
> the compositor, the lock is always disabled if the fake pointer position
> ends up outside of the given window rectangle.

I've thought through that and I haven't come up with anything better here.
I think having the relaxed rules as a special case for XWayland is
acceptable, XWayland is simply a special but important use-case. The
half-private protocol is IMO worse long-term, it's a lot harder to extend
than a private agreement.

Cheers,
   Peter

> 
> An alternative solution to using the Wayland pointer constraints
> protocols could be to introduce a half-private "wp_xwayland" protocol
> with a "warp_pointer" request, only exposed to Xwayland. This would,
> apart from making the compositors require more feature and becoming more
> complicated, largely have the same problems as mentioned above,
> requiring an "emulator" to keep track of fake positions vs real
> positions, knowing when to avoid warping, and I suspect it would work
> more or less equally well as this solution; but its worth to mention.
> 
> Apart from warping, the linked branch also adds support for confining
> pointer grabs. These requests are more directly translated to
> the equivalent Wayland protocol.
> 
> How does people feel about adding "emulation" code like this to
> XWayland? Does the approach described in this E-mail and implemented in
> the linked branch seem reasonable?
> 
> 
> 
> Jonas
> 
> 
> [0] https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/relative-pointer/relative-pointer-unstable-v1.xml
> [1] https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml