Consolidating the input stacks with libinput

Peter Hutterer

8 Oct 2014

Input stack in X.org

The current stack in X is convoluted and a mess

Input stack in X.org

The X server loads the matching driver module based on the hardware:

Section "InputClass"
        Identifier "evdev pointer catchall"
        MatchIsPointer "on"
        MatchDevicePath "/dev/input/event*"
        Driver "evdev"
EndSection

but: hardware doesn't matter much anymore

Input stack in X.org

The X server loads the matching driver module based on the hardware:

evdev for mice, keyboards, misc.
synaptics for touchpads
wacom for tablets
mouse, keyboard for non-Linux
elographics, penmount, etc. for lols

Input stack in X.org

Functionality is distributed across the server and modules

Input stack in X.org - Feature matrix

Module decides which feature is available:

Feature                 evdev           synaptics       wacom
Tapping:                no              yes             yes
MB emulation:           yes             yes             no
Gestures:               no              no              yes
Finger Scrolling:       no              yes             some
Calibration:            yes*            no*             yes*

* server provides some calibration on top

Input stack in X.org - Options galore

Combinatorial explosion of test cases

synaptics has ~70 options
evdev has ~35 options
wacom has ~69 options

→ 10e101 test combinations for synaptics alone

... not counting HW differences

... but it's not like we can test it properly anyway (see XIT)

Input stack in X.org - Testing

Testing is almost impossible without firing up an X server

but then you have other local devices to worry about
are you sure version of the server is right for this version of evdev?
also, timing is fun

Input stack in X.Org - Summary

Summary:

Features distributed across modules
No communication between modules
Impossible to test
Lots of user-exposed options

These are mostly technical issues

Input Stack in X.Org - Summary

Fixing X is not reasonable

Drivers are too entangled with the server to stand on their own

We're looking at an almost rewrite here

Input Stack in X.Org - Summary

Fixing X is not reasonable

Input stack in Wayland

Wayland makes everything better!

...maybe...

Input stack in Wayland

In Wayland, the compositor takes the role of the X server and the input modules

Every compositor re-implements evdev, synaptics, wacom, ...

Feature bingo: guess which feature doesn't work in $COMPOSITOR

Input stack in Wayland

Ideally: a single input stack for all Wayland compositors

→ libinput

http://www.freedesktop.org/wiki/Software/libinput

libinput - Overview

Started by Jonas Ådahl by forking off Weston in 2013

Currently at 0.6, stable API VerySoonNow™

Weston's input subsystem modified to be a library

Almost feature-equivalent to the X.org stack

libinput - Overview

libinput

Target user: the compositor, not the actual user or the client

libinput is not "Wayland", it doesn't care about Wayland protocol.

xf86-input-libinput is libinput wrapped into an X.Org driver

MIR? maybe, who knows...

libinput

Internals are largely hidden

multiple backends, but not exposed to the users
struct udev* in, devices out
only the configuration options that make sense
everything else is handled based on the hardware

libinput - Touchpads

Touchpad features (normal):

proper multitouch support
top and bottom software button on clickpads
two-finger scrolling
1/2/3-finger tapping
clickfinger on Apple touchpads
palm detection

libinput - Touchpads

Touchpad features (exotic):

re-routing of T440 software buttons through trackstick
trackstick wheel emulation on T440
smart disabling of the touchpad
auto-scaling of the top software buttons
disable touchpad while using the trackstick
normalized pointer acceleration

libinput - Pointer acceleration

Acceleration function copied from X server, but confusing and convoluted.

Userstudy with 41 effective data sets, testing 3 methods.

libinput - Pointer acceleration

Acceleration function copied from X server, but confusing and convoluted.

Userstudy with 41 effective data sets, testing 3 methods.

Slim advantage for the two new methods, one of them 3 LOC.

Per-device acceleration functions possible (if supported by data).

libinput - Pointer acceleration

Configuration normalised to the [-1, 1] range

libinput - Tablets

Tablet support is work-in-progress, see Lyude's talk

libinput - Configuration

Very limited configuration API:

tapping enabled (disabled by default)
touchscreen calibration
pointer acceleration speed (normalized)
natural scrolling

libinput - Testing

A useful test suite

tests multiple devices automatically
uinput based
tests without a compositor

libinput - Future

Future plans (obvious):

merge tablet support
stable API/ABI
make it a drop-in replacement for X.org

libinput - Future

Future plans (non-obvious):

"buttonbox" interface/gamepads
raw/unaccelerated mouse input
device identification system
touchpad handwriting
touchpad gestures

Questions/Suggestions?