Stylus, Wayland, libinput and kwin

Have you ever wondered how krita can turn your stylus into an eraser when you press the button? How does input handling work in Linux under wayland?

The kernel

All these key events, mouse movements and stylus events are first transmitted to the kernel via variouse hardware protocols such as USB or Bluetooth. Then the Linux kernel makes these device available via udev. Udev exposes hotplug devices to user space programs, and userspace programs can query device informations via the libudev library. However, device events are emitted by evdev interfaces. Evdev maps raw input events into generic high-level input events. You can think of this as the Linux kernel seeing input events as just a bunch of 0’s and 1’s, but after evdev it suddenly means something like mouse movements events, keystroke events, etc.

Libinput

But even with the abstraction of evdev, it is still not very convenient for user space programmers. Considering the following scenario:

The user has touched the screen in the upper left corner, but the palm has also touched the lower right of the screen. Now evdev will report two touch events, one for the finger and one for the palm. But the event we really want is the finger touch, the palm event is just noise and should be ignored.

So a software filtering algorithm has to be developed. And since Linux is such a diverse ecosystem, KDE will have to develop it, Gnome as well. It would be nice to have another library to take care of this, and that’s where libinput comes in.

Libinput listens on evdev and udev interface and reports any input event of value. Not only can we stop bothering with low-level libraries like libudev and libevdev, we get noise suppression for free!

Wayland and KWin

In Wayland, applications do not receive input events directly from system (nor do they in xorg). Instead, the compositor takes this information and passes it on to the applications. The compositor and applications communicate using wayland input protocols. The complete picture looks like this:

Kernel -> evdev -> libinput -> compositor -> application

In KDE, KWin is the compositor. KWin uses libinput to listen for all input events and figure out which events belong to which application window and send them. This also means that any button remapping must be done in KWin. Because no upstream libraries provide configuration options. This is the main difference between wayland and xorg, in wayland the compositor is responsible for more things.

While giving more power to the compositor and simplifying the overall architecture, it means that the old configuration tools like xinput will not work under wayland. Even if you run applications under xwayland, because under xwayland the original events still come from the compositor, not xorg server. And all those input remapping tools had to be rewritten in the compositor.