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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
