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

[Bastien Nocera]

On Tue, 2017-04-25 at 10:20 +1000, Peter Hutterer wrote:
> On Mon, Apr 24, 2017 at 02:19:45PM +1000, Peter Hutterer wrote:
> > 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-M
> > > > > > arch/033626.html
> > > > > > For a high-level description, see
> > > > > > http://who-t.blogspot.com.au/2017/04/inputfd-protocol-for-d
> > > > > > irect-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* :)
> 
> 
> Something like this should get you most of the way there?

Why bother with this when you could export the same data via the more
generic properties? It's not like this event is formatted like an ioctl
answer, so if we need to demarshal/parse anyway...