Wayland Relative Pointer API Progress
spitzak at gmail.com
Tue Apr 21 18:05:02 PDT 2015
Interesting. It does seem like a good idea to do remote by providing
identical device api's. This probably applies to sound output too. There
will have to be simple and obvious methods to figure out the remote
machine so that all other devices besides the display go to the same
one, and there will have to be network apis designed for each of them.
But this may be a way to avoid having every aspect of remote hardware
encoded into wayland messages.
If a client opens a device, will that interfere with wayland's reading
of the device? For instance if the client opens the mouse, will wayland
still get the mouse position such that it can revoke access when the
cursor moves out of the window?
On 04/20/2015 06:14 PM, x414e54 wrote:
> 2015/04/21 5:42 "Bill Spitzak" <spitzak at gmail.com
> <mailto:spitzak at gmail.com>>:
> > 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.
More information about the wayland-devel