Documentation on libinput_device_capability says: Capabilities on a device. A device may have one or more capabilities at a time, and capabilities may appear or disappear during the lifetime of the device. We can't currently change capabilities a caller wouldn't be able to detect the new capabilities.
Long ago there was such an event, but I think we decided to remove it because there was no use case where the capabilities were not known directly. The commit commit ab9260c5c70b95779f39069b31646ff5cf8970ad Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Thu Jan 9 13:12:23 2014 +1000 Drop capability events We don't really support devices changing capabilities at runtime. The kernel has no ability to tell us when this happens on an already-opened device and the few devices that can literally change physical capabilities (e.g. the wiimote) open up extra kernel devices instead of modifying the existing one. Thus, we don't need to notify about devices changing capabilities. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> was the one removing it, and the documentation might just be a left over from the time before that.
huh, forgot about that patch. ok, the main reason I filed this one (aside from the documentation being out-of-order with the code) is Bug 85879. I have yet to come up with a good solution to this short of changing the touchpad over to report absolute touch events. And for this we'd need the capability change at runtime. If you have any good ideas here, they're very welcome
Why is a touchpad changed into being able to output absolute coordinates? Why isn't that known to begin with? It doesn't sound like Bug 85879 would need change the feature matrix of a touchpad after adding but more making use of data discarded when abstracting the touchpad into a generic pointer device. Or am I missing something here?
well, yes, we'd know that the touchpad could to abs coordinates right from the start. so technically we could set that capability bit and never send touch events unless the touchpad changes to the handwriting mode. feels wrong though, given the percentage of users who'll ever do that. I thought about limiting it to single-finger and absolute motion (that's what I did in the Xorg hack to test it) but then you lack touch begin/end events so all your lines are connected. So I do think we need touch events, it's mostly a question of whether we send them through wl_touch or a custom side-channel.
Update: our current plan for the physical buttons on the tablet is to add a "buttonset" interface and the matching capability. To provide logical grouping of devices, a tablet like the Intuos 5 Touch should have a single struct libinput_device with the capabilities TOUCH, TABLET and BUTTONSET. This device would be fed by three event nodes. Because of how udev starts up and the path backend work the only sensible way to avoid race conditions would be to add the capabilities as the other event nodes appear. i.e. we need capability change events. That buttonset interface is still WIP atm, but it does have a case for capability events that's different to the touchpad case above.
Closing as WONTFIX. We've now merged device groups instead so we don't expect devices to change capabilities at runtime anymore. For combined devices like above we'll provide separate struct libinput_device handles with the same struct libinput_device_group reference. A capability detection event thus isn't needed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.