On Mon, Aug 28, 2017 at 2:29 AM, Pekka Paalanen <[email protected]> wrote: > On Wed, 23 Aug 2017 11:48:59 +1000 > Peter Hutterer <[email protected]> wrote: > >> For previous versions, see: >> v1: >> https://lists.freedesktop.org/archives/wayland-devel/2017-March/033626.html >> v2: >> https://lists.freedesktop.org/archives/wayland-devel/2017-April/033819.html >> >> This update is closer to v1 again than v2. Biggest change is: instead of a >> get_seat we have a get_seat_evdev request. Anything evdev is then hanging >> off that seat, basically in how it was before. The hierarchy of objects is >> thus something like this: >> >> manager >> seat_evdev >> device_evdev >> device_evdev >> device_evdev >> >> and in the future we could have other interfaces like this: >> >> manager >> seat_evdev >> device_evdev >> device_evdev >> device_evdev >> device_evdev >> seat_hidraw >> device_hidraw >> device_hidraw >> device_hidraw >> seat_w3c >> device_w3c >> device_w3c >> >> Having it split at the seat level means we don't have to pollute each >> interface with the different needs of the other interfaces. evdev is the >> easiest case, so that's done first. I dropped the extra properties, Bastien >> and I discussed this at GUADEC and we agreed it's better to implement the >> minimal version first and then see what we need before trying to come up >> with a generic solution. >> >> Cheers, >> Peter > > Hi Peter, > > on a quick read-through, this looks good to me. I have only two > comments to give at this time. > > Acked-by: Pekka Paalanen <[email protected]> > >> diff --git a/unstable/inputfd/inputfd-unstable-v1.xml >> b/unstable/inputfd/inputfd-unstable-v1.xml >> new file mode 100644 >> index 0000000..c8a0380 >> --- /dev/null >> +++ b/unstable/inputfd/inputfd-unstable-v1.xml >> @@ -0,0 +1,268 @@ >> +<?xml version="1.0" encoding="UTF-8"?> >> +<protocol name="inputfd_unstable_v1"> > > ... > >> + <event name="usb_id"> >> + <description summary="device USB vendor/product id"> >> + This event is sent in the initial burst of events before the >> + wp_inputfd_device_evdev.done event. >> + >> + This event is optional, if the required information is not available >> + for this device the event is omitted. >> + </description> >> + <arg name="vid" type="uint" summary="USB vendor id"/> >> + <arg name="pid" type="uint" summary="USB product id"/> >> + </event> > > Roderick mentioned there are other busses than USB. While true, I'm not > sure if adding a third argument for bus type gains anything compared to > keeping the event bus-specific and adding new events for each bus type. > > Adding new events for new bus types would allow the compositor to avoid > advertising devices where the client does not understand the bus. > Whether that would be good or bad, I cannot say. If a device can be > used even without understanding the bus and identity, then it would be > bad. If there could be different sets of identity arguments between > busses, then it would be good. >
The current usb_id was essentially a subset of input_fd in evdev, which is nicely generic. I think in most cases this is sufficient as long as there is a product / vendor id pair. Many current HID devices are USB or Bluetooth or else use a custom USB (or RF) based protocol (e.g. Xbox controller), but are still easily supported in current evdev. I understand that if at some point some new bus arrives, which needs some new mechanism (maybe it uses GUIDs or whatever), hen vid / pid won't work, but at least the current busses can easily be supported. How to prepare for this? Should bluetooth and others have their own vid/pid structure? Thanks, Roderick _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
