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

Wed Apr 26 22:35:43 UTC 2017

On Wed, Apr 26, 2017 at 03:49:55PM +0200, Bastien Nocera wrote:
> On Wed, 2017-04-26 at 12:00 +1000, Peter Hutterer wrote:
> > On Tue, Apr 25, 2017 at 11:16:24AM +0200, Bastien Nocera wrote:
> > > 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/20
> > > > > > > > > 17-M
> > > > > > > > > arch/033626.html
> > > > > > > > > For a high-level description, see
> > > > > > > > > http://who-t.blogspot.com.au/2017/04/inputfd-protocol-f
> > > > > > > > > or-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...
> > 
> > That was my first attempt, but tbh, it doesn't look pretty:
> > 
> > diff --git a/README.md b/README.md
> > index 2f611c5..95e9d9b 100644
> > --- a/README.md
> > +++ b/README.md
> > @@ -62,6 +62,27 @@ In alphabetical order.
> >    The bus type of this device. Permitted values are
> >    * **```bluetooth```**
> >    * **```usb```**
> > +* **```IFDA_CAPABILITY_EVDEV_EV_ABS```**:
> > +  A device capability denoting the EV_ABS capability on an evdev-
> > like file
> > +  descriptor. The value is a sequence of six hexadecimal values
> > +  describing the absinfo struction, in the order of: event code,
> > value,
> > +  minimum, maximum, fuzz, flat, resolution. For example:
> > +  "0x01;0x10;0x00;0x20;0x04;0x00;0x3" sets ABS_Y with a current
> > value of
> > +  (decimal) 16, an axis range of 0..32, fuzz 4, flat 0 and a
> > resolution of
> > +  3. The event code is limited to 16 bits, all others are 32 bit
> > values.
> > +
> > +  This property is sent once per supported event code.
> > +* **```IFDA_CAPABILITY_EVDEV_EV_KEY```**:
> > +  A device capability denoting the EV_KEY capability on an evdev-
> > like file
> > +  descriptor. The value is a sequence of hexadecimal 1-byte values
> > +  describing the bitmask, with the least sigificant byte first. The
> > sequence
> > +  "0x02;0x01" are bits 1 and 8 (zero-indexed), respectively and thus
> > the
> > +  mask for KEY_ESC and KEY_7.
> > +* **```IFDA_CAPABILITY_EVDEV_EV_REL```**:
> > +  A device capability denoting the EV_REL capability on an evdev-
> > like file
> > +  descriptor. The value is a sequence of hexadecimal 1-byte values
> > +  describing the bitmask, with the least sigificant byte first. See
> > +  IFDA_CAPABILITY_EVDEV_EV_KEY for an explanation.
> 
> Do we really expect this to be human-readable? I really wouldn't
> bother, and have a single property for the EV_KEY and EV_REL values
> (";" separated I guess), and not bother with enunciating the flag
> values. That makes using the same or similar code easy in the toolkit
> implementations. And as that property is evdev specific anyway...

human-readable means human-understandable which means human-programmable and
thus human-debugabale :) debugging this is a nightmare otherwise and
need to convert from one form to the other anyway human-readable is a big
bonus. and the lot is only sent once per device, so speed is not an issue.

> and not bother with enunciating the flag values. 

I'm not sure what you mean with this? not to specify it as bitmask? then the
format wouldn't be defined at all, making implementation more ambiguous. or
just not separating it by type?

fwiw, evemu started with just dumping bits to the file, but it's almost
incomprehensible. Have a look at the "B: " lines from evemu-record.
We needed extra steps to look at the logs each time. That's why it's now
dumping human-readable formats into the same logs. Same here, something like
"0x03;0x02" for EV_KEY can be eyeballed for correctness.

Cheers,
   Peter

> 
> >  * **```IFDA_DEVICE_GROUP```**:
> >    If set, this device may be identified as one of a set of multiple
> > logical
> >    devices that represent the same physical device. For example, a
> > controller
> > 
> > Cheers,
> >   Peter