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

[Roderick Colenbrander]

On Mon, Apr 17, 2017 at 9:05 PM, Peter Hutterer
<peter.hutterer at who-t.net> 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/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
>

We originally discussed maybe using pipes and now more unix domain
sockets for 'non kernel evdev fds'. As part of the discussion we
realized ioctls wouldn't be available. Thinking about it some more, I
think the lack of ioctl support is problematic. Sure we can use fds to
send 'struct input_event' over, but EVIOCGABS is critical for
determining capabilties and value ranges. Many others are useful too
like the revoke ones. How should this be dealt with?