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 [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()
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 > libinput_path_remove_device > - to ensure proper namespacing, libinput_create_from_udev is now > libinput_udev_create_for_seat() 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 resumed? > > 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 calling libinput_path_add_device()? 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. Nice :) > > Cheers, > Peter > > [1] https://github.com/whot/xf86-input-libinput > > _______________________________________________ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
