Hey :), On Mon, Feb 20, 2017 at 4:44 AM, Jonas Ådahl <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
