Wayland Relative Pointer API Progress
spitzak at gmail.com
Mon Apr 20 13:41:11 PDT 2015
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
> 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?
More information about the wayland-devel