Wayland Relative Pointer API Progress
Hans de Goede
hdegoede at redhat.com
Sat Apr 18 14:55:06 PDT 2015
On 18-04-15 16:03, x414e54 wrote:
>> 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
>> 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.
> 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.
Erm, I was specifically not talking about mice, I'm not so sure the above
is a good idea for mice actually, esp. since games which are playable by
mouse should most likely also be playable by trackpoint / touchpad on
laptops and we really do not want each game to re-implement touchpad
support. So no the API which I propose in very rough lines above is out
of the question for mice (and touchpads and trackpoints).
More information about the wayland-devel