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

Wed Apr 26 13:49:55 UTC 2017

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

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