On Sat, 1 Apr 2017 10:48:40 +1000 Peter Hutterer <[email protected]> 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. Hi Peter, cool, I expect these to be written down in v2. :-) > 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. Thanks for the explanation, it makes sense, particularly if the properties might be useful with other window systems, protocols, or even to-bare-hardware applications (libSDL on bare DRM/evdev?). Like Jonas said, the minimum we need in the protocol spec is a pointer to the authoritative property specification. > > This reminded me, we should probably check whether libwayland-client > > can handle 'focus_in' racing with 'destroy' without leaking the fd. I > > have no recollection if it does. That is, when the client sends > > 'destroy' at the same time the server sends 'focus_in', the client no > > longer has a live proxy (has a zombie instead), does libwayland-client > > while dropping the 'focus_in' on the floor also close the received fd. > > implementation-detail? :) > but yeah, needs fixing. Indeed a side comment. :-) > > > + > > > + <event name="focus_out"> > > > + <description summary="input fd device focus out event"> > > > + Notification that this client no longer has focus and/or access to > > > + this device. Further reads from this device's file descriptor > > > + will fail. The client must close(2) the file descriptor received in > > > > "will fail" seems a bit strong. > > well, in the case of EVIOCMUTE that's exactly what will happen, ENODEV > galore for anything after the ioctl. Having this in the protocol makes it > unambiguous what's going to happen and clear that any client that cannot > handle this case is buggy. "will fail soon" might be more precise, but I'm > not sure it's as clear. We still allow to add other fd types in the future. We don't know if those will actually fail or just go silent. Thanks, pq
pgpasrvknRb71.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
