An update on the input stack

The input stack for Linux is an essential part of interacting with our systems, but it is also an area that is lacking in terms of developers. There has been progress over the last few years, however; Peter Hutterer from Red Hat came to the 2019 X.Org Developers Conference to talk about some of the work that has been done. He gave a status report on the input stack that covered development work that is going on now as well as things that have been completed in the last two years or so. Overall, things are looking pretty good for input on Linux, though the "bus factor" for the stack is alarmingly low.

High-resolution mouse scrolling

High-resolution mouse-wheel scrolling should be arriving in the next month or two, he said. It allows for a different event stream that provides more precision on the movement of the mouse wheel on capable devices. Instead of one event per 15-20° of movement, the mouse will send two or four events in that span. Two new event types were added to the 5.0 kernel (REL_WHEEL_HI_RES and REL_HWHEEL_HI_RES) to support the feature. The old and new event streams may not correlate exactly, so they probably should not be used together, he cautioned.

Likewise, libinput has added a new event type (LIBINPUT_EVENT_POINTER_AXIS_WHEEL) for high-resolution scrolling; it should be handled with its own event stream as with the kernel events. That code is sitting on a branch; it works but it has not been merged into the master yet. For Wayland, a new event type was also added in a now-familiar pattern. He pointed to a mailing list post where all the gory details of high-resolution scrolling for Wayland was explained.

libinput user devices

Hutterer has been working on input devices simulated in user space for libinput in order to simplify testing the library. Instead of needing a real kernel device to provide evdev events to libinput, a program can pass a file descriptor to libinput as the place to read its evdev events from (instead of it opening /dev/input/event0 for example). Then the client can provide evdev events to itself, in some sense, that will be treated exactly the same as a regular evdev source by libinput. Diagrams on slides 15 and 16 in his slide deck [PDF] may help visualize the idea.

The libinput test suite takes around an hour to run and the only place it currently runs is on his laptop. The test failures are all based on timeouts that are tweaked for his system; beyond that, it needs to be run as root, has dependencies on udev and uinput, and it can mess up the login session when it is run. The test suite will not run in a container as it stands, so it is not part of the continuous-integration (CI) testing. User devices will make it easier to run the test suite in a container, but there are other use cases for the feature as well. He mentioned having a keyboard macro daemon for Wayland that would generate evdev events to be handled just as any other keyboard input. He is currently planning to put this new code in libinput-testing.so, rather than into libinput itself, but that may need to change down the road to support the other use cases.

ratbag-emu

Hutterer also mentioned ratbag-emu, which is a mouse firmware emulator that Filipe Laíns, an intern at Logitech, has been working on. When a gaming mouse needs to be configured, that is done by the ratbag daemon (ratbagd)—part of libratbag—which sends device-specific commands via a raw HID device (e.g. /dev/hidraw0). In order to test that, an actual mouse needs to be plugged in and removed multiple times.

Ratbag-emu will emulate the mouse so that the test suite can exercise ratbagd. There is a REST interface exposed by ratbag-emu that allows specific devices to be chosen for emulation and to check on the settings that were sent to them. The idea is to be able to emulate any mouse, but right now it is mostly for Logitech mice because they have full specifications for those, Hutterer said.

Tuhi

Moving on to things that had been done in the last year or two, Hutterer mentioned Tuhi, which is a GTK program to manage Wacom Smartpad devices (e.g. Bamboo Spark). These are notepads with paper that you can draw on with a pen, but underneath the device records all of the strokes made; using Bluetooth, you can retrieve the drawings. He has a recent blog post about Tuhi as well.

Tuhi does not need to be sophisticated, he said, it simply pulls down the images and provides a way to save them as SVG or PNG format files. The protocol had to be reverse engineered, but the project eventually did get some specifications from Wacom that helped untangle a few misunderstandings. The only way to get a drawing from the tablet is to get the oldest one stored there; if newer drawings are wanted, the older ones must be deleted. That makes it imperative that Tuhi not lose any drawings when it is pulling down several; there are multiple safeguards in Tuhi to ensure that, Hutterer said.

Bus factor of one

The xf86-input-evdev driver is in maintenance mode at this point. The last commit was in May 2018 and, since the 2.10.0 release four years ago, there have been a total of 19 commits. It is still shipped in RHEL 8 in order to support "crazy devices" that don't work otherwise. Similarly, xf86-input-synaptics had a 1.9.0 release in 2016 and has had nine commits since. It is effectively dead and all touchpads should be working with libinput at this point. Since libinput took over from xf86-input-synaptics three years ago, no one has stepped up to say they want to continue maintaining it, Hutterer said.

"Libinput is good and has a problem at the same time", he said. Since the 1.9.0 release roughly two years ago, it has had 1100 commits—980 of those were by Hutterer. "The bus factor is one. The input stack you are all relying on has one developer." Over those two years, there have been 50 other developers, but only four of them have more than five commits.

The move to GitLab has given him the ability to add tags to bugs, but he found that adding the "help needed" tag to libinput bugs was a reliable way to never hear anything about that bug again. Moving to GitLab has been a mixed blessing, he said. He is more efficient and the CI integration will make things even better, but, as far as he can tell, libinput changes are getting no code review. When he used to post patches to the mailing list, he would get the occasional "drive-by review", but that doesn't seem to happen when the patches are "seven clicks away in the GitLab web interface".

The story with libratbag is somewhat familiar. It was meant to be the "one true mouse-configuration API" when it was introduced four or five years ago, Hutterer said. For a year or so, that was going well but it fell by the wayside as he and others ran out of time to work on it—and no one else stepped up. There are a lot of people who want their mouse to work correctly, he said, but there are not a lot who are willing to help make that happen. Given that, he is not sure what the future holds for libratbag.

libinput quirks

Around a year and a half ago, the "libinput quirks" feature was added. There are a lot of devices that are broken in some fashion, so there needs to be a way to indicate that. For example, some devices claim to have buttons they don't have, don't claim buttons they do have, are upside down, and so on. Back in 2014, these quirks were stored in the udev hardware database (hwdb), which is a simple-to-use key/value store that is available on every system.

Over time, though, the hwdb approach became unmaintainable; libinput started using hierarchical and nested quirks that were essentially unable to be debugged. In addition, depending on how the hwdb was updated, quirks would seemingly randomly be applied or overridden. For those reasons, over the last two years the project switched to using .ini files to describe the quirks in one place that should be easy for users to find and work with.

libinput-record

The evemu utilities to record and replay event streams have been replaced with libinput-record and libinput-replay. The custom format used by evemu was not extensible, so the new tools use a YAML format. Most importantly, Hutterer said, the new tools are in the libinput repository and are released at the same time as libinput, which should eliminate the version mismatch problems that have plagued debugging efforts in the past.

Hold gestures

Something that he has been thinking about adding to libinput is "hold" gestures. It already has "swipe" and "pinch" gestures, so adding a hold gesture, where you place three fingers, for example, down on the touchpad without moving them, would make sense. There could be hold gestures for one, two, and three fingers.

The hold event might simply be the start of a pointer movement, though, so some kind of "hold cancel" event would be needed before the pointer movement events. If the fingers are placed down again, another hold event would be reported. This would allow a two-finger flick to start kinetic scrolling, which is implemented in the applications, and then to be able to detect when to stop the scrolling because the user has touched down as they saw what they were interested in scroll by. There is no code for hold gestures as yet, he said, so he encouraged those interested to get in touch to discuss how it should all work.

Hutterer covered some other topics in the talk (YouTube video) as well, including adding support for the Dell Canvas Dial totem device, which is meant as a secondary input device for menu selection on a drawing tablet. While it is now supported in libinput, he was not optimistic that any applications would actually add functionality for it. There were also some changes to simplify XKB configuration. In truth, it all sounds like quite a bit was accomplished with a really small base of developers. We need to hope that changes—and that Hutterer steers clear of buses.

[I would like to thank the X.Org Foundation and LWN's travel sponsor, the Linux Foundation, for travel assistance to Montréal for XDC.]