Wayland Relative Pointer API Progress

[Peter Hutterer]

On Tue, Apr 21, 2015 at 06:05:02PM -0700, Bill Spitzak wrote:
> 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?

unless one client issues an EVIOCGRAB on the fd, any other client will
continue to see events (and the event stream is the same on all fds). We use
this for debugging already and it is why things like evemu-record work even
when your graphical session is running.

The real problem regarding the mouse position is that you now rely on the
client and the compositor to calculate the cursor position exactly the same
way. If not, you may end up leaving the window when the cursor as drawn by
the client is nowhere near an edge (think of in-game menus). 

Go back a few years, all the VMs had this issue when they were using
relative input - the solution then was to grab the xorg pointer (i.e.
pointer locking). You can't rely on the relative events alone here.

Cheers,
   Peter

> 
> 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.
>