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

Wed Apr 26 02:00:40 UTC 2017

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

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.
 * **```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
