Hey, On Fri, 2017-03-31 at 12:23 +0300, Pekka Paalanen wrote: > On Fri, 31 Mar 2017 17:29:19 +1000 > Peter Hutterer <[email protected]> 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 _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
