[RFC v2 wayland-protocols] inputfd - direct input access protocol

[Peter Hutterer]

On Tue, Apr 18, 2017 at 11:12:18AM +0200, Bastien Nocera wrote:
> On Tue, 2017-04-18 at 14:05 +1000, Peter Hutterer wrote:
> > On Fri, Apr 07, 2017 at 01:43:57PM +0300, Pekka Paalanen wrote:
> > > On Fri, 7 Apr 2017 14:04:40 +1000
> > > Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > > 
> > > > For the initial patchset, see 
> > > > https://lists.freedesktop.org/archives/wayland-devel/2017-March/0
> > > > 33626.html
> > > > For a high-level description, see
> > > > http://who-t.blogspot.com.au/2017/04/inputfd-protocol-for-direct-
> > > > access-to.html
> > > > 
> > > > This is a relatively unexciting update, the notable bits are:
> > > > * instead of having a per-device type get_seat_* request, we now
> > > > have just a
> > > >   basic get_seat() request that returns all inputfd-capable
> > > > devices. This
> > > >   allows for mice, keyboards, etc as well without having more
> > > > requests
> > > > * the property description has a link to the github repo i
> > > > started for the
> > > >   dictionary
> > > > * the fd was split into a read/write fd to allow for pipes, the
> > > > type was
> > > >   extended for an evdev-protocol-carrying pipe. (I'm not
> > > > convinced this
> > > >   is good enough yet, just as a note)
> > > 
> > > Hi,
> > > 
> > > I don't understand the need for two fds. Yes, pipes are
> > > one-directional, but one could use a AF_UNIX socket for
> > > bidirectional
> > > comms (socketpair(2)). Having a second pipe fd for writing does not
> > > allow for a synchronous command a la ioctl() anyway.
> > > 
> > > You have read and write fds in the same event. Wayland is
> > > incapable of sending an argument of type fd that is not actually a
> > > real
> > > open file descriptor. This means that if the write fd is not
> > > needed,
> > > one still needs to create a valid open fd, send it, and close it.
> > > 
> > > Even if you send the same fd in both arguments, the receiver will
> > > receive two different valued fds. Determining if they are the same
> > > underlying "file" is... I don't actually know how to do that.
> > > Something
> > > about comparing fstat(2) information.
> > > 
> > > We had the problem with the linux_dmabuf protocol, where one needs
> > > to send a variable number of fds. We solved it by sending one event
> > > per
> > > fd.
> > > 
> > 
> > ftr, I've reverted this locally again, so we're back down to one fd,
> > thanks.
> 
> Do you have an idea on how we could extend the protocol to handle LEDs,
> and possibly other associated non-joystick devices? That seems to be
> about the only blocker left.

no epiphanies about the LEDs yet, sorry. Associated devices would have to go
through something like libinput's device group, but otherwise enabling
non-joystick devices is trivial, we can just pass the fds as we do with
joystick devices.

> Battery is just one other property we could feed to the device, but
> we'd need a way to pass it to the client without a
> connection/disconnection cycle. "update" event?

I'd make it a battery-specific event (i.e. "battery_status" or so), that's
trivial to add. The main question is the content of the event here
(percentages? levels? ...), but we can work around that problem by having
multiple events and only sending the most precise one.

Cheers,
   Peter


> > Cheers,
> >    Peter
> > 
> > > > 
> > > > This addresses some of the immediate comments. The big list of
> > > > TODO is:
> > > > * LED control, force feedback, and other write-back channels that
> > > > don't work
> > > >   on the fd but go through sysfs
> > > > * battery status and other notifications
> > > 
> > > 
> > > Thanks,
> > > pq
> > 
> >