[PATCH xwayland 5/7] xwayland: Emit relative motion events on both warp/confinement situations

[Carlos Garnacho]

Hey :),

On Mon, Feb 20, 2017 at 4:44 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
> On Sat, Nov 12, 2016 at 05:25:20PM +0100, Carlos Garnacho wrote:
>> But just as long as the cursor is hidden. In the typical pattern in
>> games of "hide cursor, grab with a confineTo, warp constantly the pointer
>> to the middle of the window" the last warping step is actually rather
>> optional.
>>
>> Some games may choose to just set up a grab with confineTo argument,
>> and trust that they'll get correct relative X/Y axis values despite
>> the hidden cursor hitting the confinement window edge.
>>
>> This makes Xwayland able to handle that pattern, downside is that
>> perhaps clinging further on the x_cursor == NULL heuristic. Whenever
>> the cursor is made visible again, the pointer will appear at whatever
>> position it was left in, and Xwayland will switch back to using abs
>> coordinates.
>
> This will mean that we might get a "jump" when the cursor is made
> visible, because it is likely that the fake cursor position that is a
> result of the relative motions, and the actual absolute position as seen
> by the compositor, eventually will become out of sync.

Yes, this is the behavior chosen by the games I saw exhibiting this
pattern. 3D-y stuff would not show any cursor so confining is
sufficient, for the transient in-game menus where the pointer is
actually needed, a Cursor could be set by the application, and the
pointer would be made visible wherever it was left last.

This is the same behavior I could see with wine on an X11 session, I
assume it's just the same in the games' original arcane platform,
since pointer warping is very thinly wrapped in Wine.

>
> And, why is this needed? The client should still get the relative
> coordinates via valuator_mask_set_absolute_unaccelerated() if there
> actually are any. Or do they expect to get both absolute, accelerated
> and unaccelerated x/y? If so, then I suppose we can just add yet another
> valuator_mask_set() function that has even more information, so that we
> avoid the jump we'd now get.

Wine not only handles both abs/rel motion (the former through core
events, the latter through XI_RawMotion) at the same time, it also
does check that the slave device axes contain Rel X/Y valuators. The
absolute xwayland-pointer device doesn't pass this check, and thus
only MotionNotify is handled.

And I guess that's the same reason why we have
xwayland-relative-pointer for X11 native gam^Wclients? Maybe Wine
could do without the rel valuators checks, but since it does actually
pursue a behavior compatible with something else and it apparently
obtains it on an X11 session, it made sense to me to extent the
Xwayland heuristics to cover this.

I agree the cursor jump is not pretty, but after all it's the client
requesting it, even if through a bewildering amount of compatibility
layers :).

Cheers,
  Carlos