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

[Peter Hutterer]

On Mon, Sep 11, 2017 at 05:04:00PM -0700, Jingkui Wang wrote:
> qq inline
> 
> On Tue, Aug 22, 2017 at 3:46 PM, Peter Hutterer <peter.hutterer at who-t.net>
> wrote:

[...]

> > +  <interface name="zwp_inputfd_device_evdev_v1" version="1">
> > +    <description summary="evdev-compatible inputfd device">
> > +      The wp_inputfd_device_evdev interface represents one device node
> > +      in the Linux kernel evdev interface. The fd passed to the client
> > +      supports the ioctls and read/write commands of that interface. The
> > +      protocol makes no guarantees which ioctls are available on the fd,
> > +      this decision is made by the kernel.
> > +
> > +      A device has a number of static characteristics, e.g. device
> > +      name and pid/vid. These capabilities are sent in an event sequence
> > +      immediately after the wp_inputfd_seat.device_added event. This
> > initial
> > +      event sequence is terminated by a wp_inputfd_device_evdev.done
> > event. This
> > +      sequence is sent only once and always before the first
> > +      wp_inputfd_device.focus_in event.
> > +
> > +      A device is the representation of a logical device as exposed by the
> > +      underlying system and may only represent parts of a single physical
> > +      input device. It is the client's task to identify the device as part
> > +      of a physical device and to group the logical devices together as
> > +      appropriate.
> > +    </description>
> > +
> > +    <request name="destroy" type="destructor">
> > +      <description summary="destroy the inputfd object">
> > +       This destroys the client's resource for this inputfd object.
> > +      </description>
> > +    </request>
> > +
> > +    <event name="name">
> > +      <description summary="device name">
> > +       The name is a UTF-8 encoded string with the device's name, intended
> > +       for presentation to the user.
> > +
> > +       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="name" type="string" summary="the device name"/>
> > +    </event>
> > +
> > +    <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>
> > +
> >
> Is there a way to pass through device identification here? Something like
> "ID_INPUT_KEYBOARD"?

I don't think that's going to help much. ID_INPUT_* is too coarse and prone
to being wrong, especially on the devices that we're interested here. if
you're dealing with a device directly I think you should be able to tell
what it is based on the evdev description.

> Does "seat_evdev" indicate client interested in all evdev devices?

yes, you can always destroy/ignore those that you don't care about.
note that the compositor can filter devices, so you may not see all devices
in the inputfd seat.

Cheers,
   Peter