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

[Peter Hutterer]

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

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