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

[Peter Hutterer]

On Sun, Apr 23, 2017 at 09:47:20AM -0700, Roderick Colenbrander wrote:
> 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?

there are two parts to that question. The first one is effectively "how to
deal with device capabilities", i.e. EVIOCGABS and friends. Those can be
handled on a side-channel, either through the IFDA properties or as real
events on the wayland protocol. (ioctl is a side-channel too, so it's not 
even that different). Obviously, as events on the wayland protocol we could
guarantee things like event ordering and only send them on the first focus
in, etc. IFDA properties give us the extensibility advantages,
so... *shrug* :)

The second part is "what about other ioctls" but here the question is what
you really want to achive. 'revoke' isn't something you should need here,
right? that's the compositor's job. masking, clock-id, and grab are the
same, they shouldn't be needed. That only leaves force feedback ioctls, but
these need to be solved anyway (like LEDs, I don't have a good solution here
yet).

Cheers,
   Peter