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

[Peter Hutterer]

On Sat, Apr 01, 2017 at 12:55:57PM +0800, Jonas Ådahl wrote:
> 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.
> 

Mostly for the archives, Timo Paulssen pointed me to 
https://github.com/denilsonsa/udev-joystick-blacklist
At least for the compositor's side of things this is a good start, it's
independent of this protocol though.

Cheers,
   Peter