Wayland Relative Pointer API Progress

[Bill Spitzak]

On 04/18/2015 03:20 AM, Hans de Goede 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
> issue).
> 4) Hand a new evdev fd to the app when it regains access.

This makes sense though I can see some problems if you try to run a game 
on a remote machine, since there is no fd that will work (unless there 
is a network protocol added to communicate all devices, but if that is 
the case why not reuse Wayland's protocol?).

I don't know what other platforms do, but perhaps it is acceptable if 
the number of raw devices can be empty. A client can then either fail 
gracefully, or try to do the best it can with the wl_pointer api. 
Anybody have any examples, is there rdp access to fancy input devices on 
Windows? So when you run your game remotely you are limited to the mouse 
emulation no matter how fancy your controller is.

It is likely that the method used to transform a device into wl_pointer 
positions is controlled by user preferences, so there will need to be a 
design such that the client can see these user preferences and replicate 
them when using the raw device.

For #3 can the compositor somehow force the opened fd to close?