Wayland Relative Pointer API Progress

[x414e54]

On Thu, Apr 23, 2015 at 1:51 PM, x414e54 <x414e54 at linux.com> wrote:
> On Wed, Apr 22, 2015 at 1:52 PM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
>> The real problem regarding the mouse position is that you now rely on the
>> client and the compositor to calculate the cursor position exactly the same
>> way. If not, you may end up leaving the window when the cursor as drawn by
>> the client is nowhere near an edge (think of in-game menus).
>
> I am not sure it is much different to what we have today:
>
> If they are using it for a cursor for 2D in-game menus or a remote
> client it really should be using the absolute wl_pointer position
> driven by all of the "SlavePointers" in X11.
> e.g. MotionNotify
>
> When you open a device for raw access you intend that you will not be
> paying attention to acceleration or normalization so you cannot draw a
> cursor synced with the system.
> e.g. XI_RawMotion
>
> Currently on X11 I believe you have to grab the "CorePointer" always?
> But it would be much nicer if you could just detach/reattach the
> single "SlavePointer" if the game was going to use that for non cursor
> driven input.

I guess there is the situation also where you want to constrain the
wl_pointer the window such as scrolling a scene based on proximity to
the edge of the window in an RTS.

Some games are nice about this in that they unlock the pointer when
the game is paused but some just grab and confine the pointer always
meaning there is no way to reposition the window without doing some
kind of alt-tab dance. Then when you do alt tab they scroll you over
to the other side of the map because your pointer was outside of the
window.

It is this kind of situation that is probably the main issue.