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

[Jonas Ådahl]

On Sat, Apr 01, 2017 at 10:48:40AM +1000, Peter Hutterer wrote:
> On Fri, Mar 31, 2017 at 12:23:49PM +0300, Pekka Paalanen wrote:
> > > +      <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.
> > 
> > This raises a couple of questions for the protocol itself:
> > 
> > - What should the client do with a property or value it does not
> >   recognize?
> > 
> > - If the client does not recognize a property or a value, can it still
> >   use the device? Could this vary per property?
> > 
> > - Should the compositor be sending only properties and values the
> >   client can understand?
> > 
> > If this protocol does not define a single authority on the dictionary,
> > should it then carry a dictionary type, id or namespace?
> > 
> > Should properties be namespaced?
> 
> ok, easy answers first :)
> 
> clients must ignore property names or values that they do not understand,
> the compositor may send any value (it won't know what the client supports),
> the protocol does not enforce namespacing, but the dictionary authority may
> do so.
> one more thing I thought of: properties key/values are *not* singular, a
> client may receive the same property with multiple different values (e.g.
> ORIENTATION=left, ORIENTATION=top or BUTTON=A, BUTTON=X, ...). Whether
> that's allowed for any property depends on the dictionary.
> 
> Now to the difficult answers:
> 
> I think it'll be impossible to *not* have this in an external dictionary.
> The needs of the compositor and the clients are both the same and completely
> different for this protocol to work correctly. Let's take the example of
> tagging a device as gamepad. The default udev rules are unreliable,
> ID_INPUT_JOYSTICK has too many false positives. So we need some database
> that tags the device as JOYSTICK_TYPE=gamepad, JOYSTICK_TYPE=wheel, etc.
> That can be done in udev, but needs some external authority anyway -
> libwacom style. Without that, you'll have a mismatch in what compositors
> detect as gaming devices vs what clients can handle (assuming the mythical
> libgamingdevice exists).
> 
> The compositor doesn't care about the actual value though, anything with
> JOYSTICK_TYPE is a gaming device and will be accessible through inputfd.
> Adding new joystick types in the future does not change the protocol or the
> compositor implementation. A client should not need to wait for protocol bumps just
> to get access to a new type that the compositor doesn't care about anyway.
> Just as a general reminder, the whole point of this protocol is for the
> compositor to have some say in what's available but otherwise get out of the
> way.
> 
> If we don't have the generic properties, we need the client to have some
> other way to access information about the device. In the Wacom case we have
> 'path' which gives the client a syspath and thus the udev device and access
> to udev properties. Bastien wasn't too happy about this for GPIO devices
> where it may not be possible, so the property approach was the first thing
> that came to mind.
> 
> Having said this - while I don't want this in the protocol, there's no
> reason we can't define that dictionary authority ourselves. I just want it
> external to the protocol. ICCCM/EMWH-style, effectively. But I would feel
> uncomfortable *being* the authority, given that this is too far outside my
> core knowledge. Happy to be the maintainer for this though, an initial
> implementation would be largely boilerplate.
> 
> I still think that there's a market for a generic libgamingdevice library
> that works libinput-style for gaming devices and provides the database that
> matches this dictionary. 
> 

The main reason I can think of for having an external authority for a
generic property set is if these properties are not going to be specific
to this protocol, but in this case, the backward compatibility
requirements must be the same, and the protocol cannot be skip
specifying who the authority actually is, as otherwise it'd make the
property completely undefined thus useless. A compositor cannot possibly
know what to put there, and a client cannot possible know what to
expect, and it might end up different for each compositor, doing what
they think is "right", as is with undefined behavior.

However, if these properties are to be specific to this protocol, I see
no practical reason for outsourcing. Adding properties to an existing
protocol is extremely easy, and making a wayland-protocols release just
for properties is not an issue. Who ever would be the gate keeper of a
potential outsourced authority could be a maintainer for the protocol in
wayland-protocols and do the same there. I can understand why it might
be desirable to outsource it to something like a libgamedev, it
shouldn't lessen any requirements of what to add to the dictionary.

Anyhow, the way I see it, either the protocol itself defines available
properties, or we outsource them to something known that does it for us,
that has the same kind of requirements as if they would be added here
directly. What matters most is that it is clear what to expect to
put/get. If any property is to be required, it would still have to be
added to the protocol however and associated with a particular version.

FWIW, creating a libgamingdev repository that just contains a property
specification text file and a hwdb file, could potentially be a good
enough authority.


Jonas