veyepar: "Write a single library to handle all input devices, it'll be easy" they said...

Author(s):	Peter Hutterer
Location	Room 5
Date	jan Fri 17	Days Raw Files
Start	13:30	First Raw Start	error-in-template
Duration	0:45:0	Offset	None
End	14:15	Last Raw End
Chapters
Total cuts_time	None min.

https://lca2020.linux.org.au/schedule/presentation/79/
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf Write_a_single_library_to_handle_all_input_devices_itll_be_easy_they_said.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

Six or so years ago, input devices in userspace were handled by a set of different modules, all with their own properties and behaviours. Where a device didn't work as expected, it was largely up to the users to find the right forum with examples that actually work. This had worked "well" for about a decade or two.

Then, largely driven by the promise of the differently-shaded pastures of Wayland, a new library was born: libinput. The prime motivation behind this library was to have a  unified input stack that works well out of the box for any device, regardless of the display server. libinput is now the input backend for all major Wayland compositors and the default X.org input driver.

This talk goes through the motivations behind libinput and its design choices. Why and how is it different to what we had before? Why can we handle mice, touchpads, tablets, touchscreens but not joysticks? Or the weird but common question: Why are there no configuration options? (Spoiler alert: there are quite a few.) The talk will explain how some of the devices work, how we handle them and  why certain behaviours are required and/or at last need to be worked around. I will explain the various current and future features and our plans to improve them. And where we went wrong. Because if it wasn't for the error part of "trial and error", everyone would think that we know what we're doing.

This talk is about technical details, but intended to be accessible to everyone. You won't need to know programming to understand it, but you'll probably leave knowing more about devices than you want to know.

Comment:

production notes