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:

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

→ 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

Input stack in X.Org - Summary

Summary:

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 - 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

libinput - Touchpads

Touchpad features (normal):

libinput - Touchpads

Touchpad features (exotic):

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:

libinput - Testing

A useful test suite

libinput - Future

Future plans (obvious):

libinput - Future

Future plans (non-obvious):

Questions/Suggestions?