Wayland Relative Pointer API Progress

[x414e54]

> Right.
>
> This has been discussed before, and as mentioned before I really
> believe that we should not define a joystick API at all,
> rather we should define an API which will allow an app to:
>
> 1) List devices which it can get raw access to
> 2) Request raw access, if this succeeds the app will be handled
> an evdev fd for the device
> 3) Notify the app that the compositor is revoking access (e.g.
> because the app lost focus), when this happens the compositor
> will do a revoke ioctl on the evdev fd rendering it useless
> to the app, so the app cannot keep using this (so no security
> issue).
> 4) Hand a new evdev fd to the app when it regains access.
>
> This will allow whatever gaming crazy devices pop up to work,
> and will allow force feedback to work too.
>
> I think that trying to define a wayland "controller" protocol for
> this is not a good idea, we will just end up wrapping evdev and
> adding a whole lot of unnecessary indirection. Currently
> games (e.g. libSDL) already are used to opening raw evdev nodes,
> by moving the enumeration + actual opening into the compositor
> we are fixing the security concerns of the old approach while
> keeping all the good bits of it (mainly giving games raw
> access to complex input devices), and this also solves the
> seat assignment problem neatly.
>
> Regards,
>
> Hans

Yes I agree this is the best option and it should be used to implement
mouse support in games. They get the fd and can get all of the
unaccelerated raw relative information they need. There are also other
cases like mice which have RGB LEDS and the game will want to change
the color of these. This also allows support for multiple pointers in
games which do not all drive the system pointer.

The pointer focus still needs to be constrained or the device unhooked
from the system pointer but only in the case that the device opened is
the same as the system pointer one and the application asks for it to
be hidden. I think in most cases in a game if the pointer is visible
it should be allowed to escape the window.