[PATCH libinput 0/6] Add dynamic devices to the path backend
jadahl at gmail.com
Thu Feb 6 13:23:57 PST 2014
On Thu, Feb 06, 2014 at 02:13:04PM +1000, Peter Hutterer wrote:
> 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  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
> 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()
Why not just libinput_path_create()?
> 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
> - to ensure proper namespacing, libinput_create_from_udev is now
These API changes looks good to me, but should maybe suspend and resume
behaviour be documented? Is it required to re-add devices after having
> 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).
So I guess you can't just add and then flush and process the queue right
there, as the DEVICE_ADDED event will already have been queued when
We could also simply expose the devnode to the caller as well,
caching and matching later is not very nice.
> On the positive side, the xorg driver seems to be working quite nicely
> already, though it is rather featureless.
>  https://github.com/whot/xf86-input-libinput
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
More information about the wayland-devel