[PATCH libinput 0/6] Add dynamic devices to the path backend

[Peter Hutterer]

This patchset revamps the path backend to allow for more than one path-based
device per context. I thought the initial approach of having one context per
device is sufficient but there are a few use-cases that can really only be
solved by having libinput control all devices. A common example is disabling
the touchpad while typing, or making the trackstick buttons on the Lenovo
T440s useful.

So for my little libinput-based xorg driver [1] I need to have a shared
context between the various devices added. The change looks bigger than it
is, it largely just replicates what the udev-seat backend already does
anyway.

Most notable there are a few API changes:
- libinput_create_from_path() has been removed, a caller should now use
  libinput_path_create_context(), then libinput_path_add_device()
  I found this to be nicer in the caller code than having
  libinput_path_create_from_device() and then adding devices.
- more devices can be added or removed with libinput_path_add_device and
  libinput_path_remove_device
- to ensure proper namespacing, libinput_create_from_udev is now
  libinput_udev_create_for_seat()

So far this looks flexible enough for the xorg drivers which have different
use-cases than in weston, specifically each device can be disabled and
enabled individually. I just call remove/add device when that happens.

What's not so nice is a shortcut in libinput_path_add_device(). Instead of
just succeeding and letting the caller handle the DEVICE_ADDED event, it
returns the struct libinput_device directly. At least within the xorg driver
context I found it too hard to work with the events (long description on
request) but the short summary is that I'd need to cache any events before
DEVICE_ADDED and use timers to re-trigger the read once I have the device,
aside from the problem of not being able to figure out which device is which
based on the events only (we don't expose the devnode to the caller).

On the positive side, the xorg driver seems to be working quite nicely
already, though it is rather featureless.

Cheers,
  Peter
 
[1] https://github.com/whot/xf86-input-libinput