On Mon, Aug 28, 2017 at 01:55:16PM -0700, Roderick Colenbrander wrote: > 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?
afaict the bluetooth vid/pid (at least on hid devices) is the same as the usb vid/pid, right? So the only addition we'd need there would be maybe a 'mac' event or so if the physical address is important. but basically - yes, we'd add new events for the bits we can't service well. As with the rest of the protocol, I'd rather have a new event added that fixes the use-case we need than try to design a "one size doesnt quite fit anyone" event ahead of time. Been there, done that, bought the tshirt [1] Cheers, Peter [1] it doesn't quite fit. _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
