Wayland Relative Pointer API Progress

[Bill Spitzak]

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.