Wayland Relative Pointer API Progress

[Hans de Goede]

Hi,

On 18-04-15 03:35, x414e54 wrote:
>> A big problem with just saying "the game must use the joystick api" is that
>> the game won't work on a machine without a joystick unless the joystick api
>> is emulated for the mouse. This seems to me to be exactly the same problem
>> and requiring exactly the same solutions, except you have moved the code
>> from the client to the compositor, which is usually a bad idea. Also you
>> have made it a pain in the ass to create simple toolkits since they now have
>> to provide the joystick api.
>
> By joystick I mean "generic axis device with buttons" we do not mean
> an actually joystick, "controller api" may be a better word. If my
> gaming mouse has 40 buttons, and a 7000+ dpi laser 3D mouse wheel (not
> just the movement sensor), I want ALL of that information not just
> what the wayland protocol designers think is best.
>
> Obviously a "joystick" is confusing and more restrictive than allowing
> the full access to the device marshalled by the compositor and then
> the user can run it though whichever api they want this is why I
> prefer Jonas' idea of using the actual evdev device but the compositor
> can MITM the char buffer or something similar.
>
> This is EXACTLY how games work on other platforms when using mouse,
> they either use a raw USB/HID input api or in the case of older games
> older than windows xp they use directinput. Obviously on windows you
> would use xinput (which will do more abstracting for you) and rawinput
> but on mac you use HIDManager for everything which also supports raw
> mouse input. The point is using a well abstracted api you can do not
> care what you get as long as it has at least 2 relative axis and 2
> buttons.
>
> You want the compositor todo this because the game knows nothing about
> which evdev input device is associated with which seat, how does it
> know what to open? Also this would be good from a security side as you
> do not have to allow full user access to the evdev device which
> another user on the same system may want to use. You can have the
> compositor refer to a security or sandboxing api.

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