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