Wayland Relative Pointer API Progress

[Peter Hutterer]

On Sun, Apr 19, 2015 at 12:45:09PM +0100, Steven Newbury wrote:
> On Sun, 2015-04-19 at 15:29 +0900, x414e54 wrote:
> > 
> > 
> > The way todo this seems to be for the compositor and client to 
> > negotiate an event type they both can understand such as
> > libinput_event or hid events and then a way to request a revokable 
> > fd to the evdev directly so it can control LEDS and force feedback 
> > etc. This allows for applications and compositors to grow separately 
> > of the wayland protocol so it does not need updating every time 
> > someone invents some new mouse device which needs 128bit integers 
> > instead of doubles, has a z axis, thumbstick or tiny projector built 
> > in, etc.
> > 
> 
> There's also the point that nothing stops games or sdl-like layers 
> from using libinput to interpret the evdev stream, there's no need to 
> keep re-implementing device handlers for each client, that way new 
> devices supported by Wayland are automaticaly supported.

there is a minor problem: libinput can't open a device based on the fd
alone. there's a clunky workaround in the xorg libinput driver (see the
open_restricted implementation there). 

I'm willing to consider an API that passes an fd to libinput instead of a
path though. Pls file a bug whenever we're at the point where we really need
it, iirc I even had that implemented or at least partially implemented at
some point.

Cheers,
   Peter