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

[Peter Hutterer]

On Wed, Aug 23, 2017 at 11:41:27AM -0700, Roderick Colenbrander wrote:
.
> > +    <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>
> 
> Minor, but should this be named usb id? There are other various
> wireless busses as well.

good point. This is modelled after the evdev input_id struct, so I guess
adding a bustype to it and just naming it "id" would be good enough for the
majority of use-cases.

> > +    <event name="focus_in">
> > +      <description summary="input fd device focus in event">
> > +       Notification that this client now has the focus and/or access to
> > +       this device. How focus is set is left to the
> > +       compositor. For example, a compositor may tie joystick focus to the
> > +       wl_pointer focus of this seat. The protocol does not guarantee that
> > +       any specific client ever receives the focus for a device.
> > +
> > +       The client is passed a file descriptor with access to this
> > +       device. This file descriptor is valid until a subsequent
> > +       wp_inputfd_device_evdev.focus_out event. Upon
> > +       wp_inputfd_device_evdev.focus_out, the compositor may revoke the fd
> > +       and further operations will fail.
> > +
> > +       However, due to potential race conditions a client must be able to
> > +       handle errors as if it opened the fd itself. No guarantee is given
> > +       that the wp_inputfd_device_evdev.focus_out event or
> > +       wp_inputfd_device_evdev.removed event are sent before the client
> > +       encounters an error on the file descriptor.
> > +
> > +       A compositor guarantees the file descriptor for a
> > +       wp_inputfd_device_evdev refers to the same kernel device after each
> > +       focus_in event. In other words, any constant information about the
> > +       device obtained through the fd (e.g. the EVIOCGPROP ioctl) is
> > +       the same after each focus in event. Thus, a client needs to do so
> > +       only once at the first focus_in. This guarantee does not extend to
> > +       information that the kernel may change at runtime (e.g. the
> > +       EVIOCGABS ioctl).
> > +
> > +       If applicable, this event contains the surface that has the focus.
> > +       In some cases, the focus may not be tied to a specific client surface
> > +       but is given to the client independent of any surface. In that case,
> > +       the surface is null.
> > +
> > +       The protocol guarantees that focus_in and focus_out always come in
> > +       pairs. If the client currently has the focus and the device is
> > +       removed, a focus_out event is sent to the client before the
> > +       wp_inputfd_device_evdev.removed event.
> > +      </description>
> > +      <arg name="serial" type="uint"/>
> > +      <arg name="fd" type="fd" summary="file descriptor to the device"/>
> 
> The only concern I have is whether the fd is enough to know everything
> about a device e.g. be able to locate sysfs entries just from the fd.
> Since I wasn't sure I did some digging. My first attempt was to use
> EVIOCGPHYS, which for many HID devices seems to return hardware bus
> information, which with some parsing could be mapped to a sysfs path.
> However many older devices don't put reliable data in here, so this is
> unreliable.
> 
> My next step was to see if instead of constructing a hardware bus path
> to a sysfs device, we could maybe use /sys/dev/char/<major>:<minor>.
> It looks like we could the major and minor number from fstat on the
> fd, so it seems possible to get to sysfs just from the fd without any
> other information.

fwiw, this is what we use in libinput to get the udev device. run fstat() on
the fd, pass the st.st_rdev into udev_device_new_from_devnum() and you're
good, at least unless you're running in flatpak or some other environment
where udev/sysfs isn't available. Obviously the manual syspath like you said
above will work too.

biggest problem is the race condition that happens when a device is removed
and re-added between fstat and the udev init call. I don't have a good
solution for that (beyond comparing usb ids) and have failed to come up with
one so far.

Cheers,
   Peter