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

[Roderick Colenbrander]

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?

Thanks,
Roderick