[RFC v3 wayland-protocols] inputfd - direct input access protocol

[Peter Hutterer]

On Mon, Aug 28, 2017 at 01:55:16PM -0700, Roderick Colenbrander wrote:
> On Mon, Aug 28, 2017 at 2:29 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > On Wed, 23 Aug 2017 11:48:59 +1000
> > Peter Hutterer <peter.hutterer at who-t.net> 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 <pekka.paalanen at collabora.co.uk>
> >
> >> 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.