Over the past couple of days, I’ve been trying to figure out how input in Linux works on modern systems. There are lots of small pieces at various levels, and it’s hard to understand how they all interact. Things are not helped by the fact that things have changed quite a bit over the past couple of years as HAL – which I helped write – has been giving way to udev, and existing literature is largely out of date. This is my attempt at understanding how things work today, in the Ubuntu Lucid release.
Kernel
In the Linux kernel’s input system, there are two pieces: the device
driver and the event driver. The device driver talks to the
hardware, obviously. Today, for most USB devices this is handled by
the usbhid driver. The event drivers handle how to expose the
events generated by the device driver to userspace. Today this is
primarily done through evdev, which creates character devices
(typically named /dev/input/eventN) and communicates with them
through struct input_event messages. See
include/linux/input.h
for its definition.
A great tool to use for getting information about evdev devices and events is evtest.
A somewhat outdated but still relevant description of the kernel input
system can be found in the kernel’s
Documentation/input/input.txt
file.
udev
When a device is connected, the kernel creates an entry in sysfs for
it and generates a hotplug event. That hotplug event is processed by
udev, which applies some policy, attaches additional properties to the
device, and ultimately creates a device node for you somewhere in
/dev.
For input devices, the rules in
/lib/udev/rules.d/60-persistent-input.rules are executed. Among the
things it does is run a /lib/udev/input_id tool which queries the
capabilities of the device from its sysfs node and sets environment
variables like ID_INPUT_KEYBOARD, ID_INPUT_TOUCHPAD, etc. in the udev
database.
For more information on input_id see the original announcement
email to the
hotplug list.
X
X has a udev config backend which queries udev for the various input
devices. It does this at startup and also watches for hotplugged
devices. X looks at the different ID_INPUT_* properties to
determine whether it’s a keyboard, a mouse, a touchpad, a joystick, or
some other device. This information can be used in
/usr/lib/X11/xorg.conf.d files in the form of MatchIsPointer,
MatchIsTouchpad, MatchIsJoystick, etc. in InputClass sections to
see whether to apply configuration to a given device.
Xorg has a handful of its own drivers to handle input devices, including evdev, synaptics, and joystick. And here is where things start to get confusing.
Linux has this great generic event interface in evdev, which means that very few drivers are needed to interact with hardware, since they’re not speaking device-specific protocols. Of the few needed on Linux nearly all of them speak evdev, including the three I listed above.
The evdev driver provides basic keyboard and mouse functionality,
speaking – obviously – evdev through the /dev/input/eventN
devices. It also handles things like the lid and power switches.
This is the basic, generic input driver for Xorg on Linux.
The synaptics driver is the most confusing of all. It also speaks evdev to the kernel. On Linux it does not talk to the hardware directly, and is in no way Synaptics(tm) hardware-specific. The synaptics driver is simply a separate driver from evdev which adds a lot of features expected of touchpad hardware, for example two-finger scrolling. It should probably be renamed the “touchpad” module, except that on non-Linux OSes it can still speak the Synaptics protocol.
The joystick driver similarly handles joysticky things, but speaks evdev to the kernel rather than some device-specific protocol.
X only has concepts of keyboards and pointers, the latter of which includes mice, touchpads, joysticks, wacom tablets, etc. X also has the concept of the core keyboard and pointer, which is how events are most often delivered to applications. By default all devices send core events, but certain setups might want to make devices non-core.
If you want to receive events for non-core devices, you need to use
the XInput or XInput2 extensions for that. XInput exposes core-like
events (like DeviceMotionNotify and DeviceButtonPress), so it is
not a major difficulty to use, although its setup is annoyingly
different than most other X extensions. I have not used XInput2.
Peter Hutterer’s blog is an excellent resource for all things input related in X.