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

[Bastien Nocera]

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.

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?

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