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

[Bastien Nocera]

Hey,

On Fri, 2017-03-31 at 12:23 +0300, Pekka Paalanen wrote:
> On Fri, 31 Mar 2017 17:29:19 +1000
> Peter Hutterer <peter.hutterer at who-t.net> wrote:
> 
<snip>
> > +    <event name="property">
> > +      <description summary="device capability notification">
> > +	This event is sent to notify the client of a custom
> > property that
> > +	applies to this device. The property is a standard
> > key/value store
> > +	in UTF-8 format, interpretation of both strings is left to
> > the
> > +	client. The wayland protocol makes no guarantees about the
> > content
> > +	of each string beyond its text encoding.
> > +
> > +	Compositors and clients need to agree on a dictionary of
> > properties.
> > +	For example, a compositor may designate the device to be
> > of
> > +	'joystick-type' 'gamepad'. This dictionary is out of the
> > scope of
> > +	this protocol.
> > +      </description>
> > +      <arg name="property" type="string" summary="A UTF-8 encoded
> > property name"/>
> > +      <arg name="value" type="string" summary="A UTF-8 encoded
> > property value"/>
> > +    </event>
> 
> While I understand the desire to leave the dictionary for others to
> specify, this event is essentially useless without it. The dictionary
> really is part of the protocol, even if you didn't want it. I'm not
> sure it's helpful to leave the authority on the dictionary
> unspecified.
> As you wrote, they need to be agreed somewhere.

As we only ever mention one "fd_type" in the protocol, I'll comment a
bit on it, and its use of properties

In udev, there are scripts to extract data from the devices, to do
things with the device, without having access to the device, eg. the
builtin input_id has code and heuristics to detect whether something is
a keyboard, a mouse, both, or a joystick, etc.

https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-input_id.c

Further down the stack, when and if the device is correctly tagged,
most of the properties you could attach to a device can be gathered
through the file descriptor you just got, and a couple of ioctls().
That includes the vid/pid, device names, bus used, the events it can
produce and buttons it claims to have, etc.

There are however some properties that the application wouldn't be able
to access if it were inside a sandbox, such as hwdb quirks:
https://github.com/systemd/systemd/pull/5413

In short, here's a first pass at a list of properties, and whether
their requirement depending on the fd_type:
- vid, pid, product and vendor names (optional for evdev fd_type)
- integration type (defaults to external if not present)
- bus type (optional for evdev fd_type), with possible values being:
  - usb
  - bluetooth
  - others?
- opaque identifier (device serial if available), so that
wireless/wired transitions can be easily done within the app

Looking forward to this functionality so games can be sandboxed but
still use joysticks.

HTH