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

[Peter Hutterer]

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-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* :)


Something like this should get you most of the way there?

diff --git a/unstable/inputfd/inputfd-unstable-v1.xml b/unstable/inputfd/inputfd-unstable-v1.xml
index 027ce1b..e613e80 100644
--- a/unstable/inputfd/inputfd-unstable-v1.xml
+++ b/unstable/inputfd/inputfd-unstable-v1.xml
@@ -177,6 +177,51 @@
       <arg name="pid" type="uint" summary="USB product id"/>
     </event>
 
+    <event name="evdev_bit">
+      <description summary="evdev capability notification">
+	This event signals the evdev capability on the given device and
+	reflects a set bitmask as returned by the EVIOCGBIT ioctl.
+
+	Note that this event is not sent for any code under the EV_ABS
+	type, see evdev_abs_info instead.
+	Note that this event is not sent for any code under the EV_SYN
+	type, these codes are impliclity enabled on all devices.
+
+	This event is sent multiple times, once for each supported event
+	code. The set of these events is the description of the device
+	capabilities. The set of these events is only sent once for each
+	device as part of the initial burst before the done event.
+
+	This event is valid for the socket_evdev fd type only.
+      </description>
+      <arg name="type" type="uint" summary="evdev event type"/>
+      <arg name="code" type="uint" summary="evdev event code"/>
+    </event>
+
+    <event name="evdev_abs_info">
+      <description summary="evdev absolute axis capability notification">
+	This event signals the evdev capability on the given device and
+	reflects a set bitmask as returned by the EVIOCGABS ioctl.
+
+	This event is sent multiple times, once for each supported EV_ABS
+	event code.
+
+	This event is sent multiple times, once for each supported event
+	code. The set of these events is the description of the device
+	capabilities. The set of these events is only sent once for each
+	device as part of the initial burst before the done event.
+
+	This event is valid for the socket_evdev fd type only.
+      </description>
+      <arg name="code" type="uint" summary="evdev EV_ABS event code"/>
+      <arg name="value" type="uint" summary="evdev EV_ABS current value"/>
+      <arg name="minimum" type="uint" summary="evdev EV_ABS minimum value"/>
+      <arg name="maximum" type="uint" summary="evdev EV_ABS maximum value"/>
+      <arg name="fuzz" type="uint" summary="evdev EV_ABS fuzz value"/>
+      <arg name="flat" type="uint" summary="evdev EV_ABS flat value"/>
+      <arg name="resolution" type="uint" summary="evdev EV_ABS resolution value"/>
+    </event>
+
     <event name="property">
       <description summary="device capability notification">
 	This event is sent to notify the client of a custom property that
 

Cheers,
   Peter