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?
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
