evdev

Docs » The Linux Input Documentation » Linux Input Subsystem userspace API » 1. Introduction View page source Input subsystem a collection of drivers that is designed to support all input devices under Linux. Most of the drivers reside in drivers/input, although quite a few live in drivers/hid and drivers/platform. These modules talk to the hardware (for example via USB), and provide events (keystrokes, mouse movements) to the input module. These modules get events from input core and pass them where needed via various interfaces - keystrokes to the kernel, mouse movements via a simulated PS/2 interface to GPM and X, and so on. This device usually created automatically by the system. The commands to create it by hand are: When you do all of the above, you can use your USB mouse and keyboard. Event handlers distribute the events from the devices to userspace and in-kernel consumers, as needed. evdev is the generic input event interface. It passes the events generated in the kernel straight to the program, with timestamps. The event codes are the same on all architectures and are hardware independent. This is the preferred interface for userspace to consume user input, and all clients are encouraged to use it. There are two ranges of minors: 64 through 95 is the static legacy range. If there are more than 32 input devices in a system, additional evdev nodes are created with minors starting with 256. Each mouse device is assigned to a single mouse or digitizer, except the last one - mice . This single character device is shared by all mice and digitizers, and even if none are connected, the device is present. This is useful for hotplugging USB mice, so that older programs that do not handle hotplug can open the device even when no mice are present. joydev implements v0.x and v1.x Linux joystick API. See Programming Interface for details. hid-generic is one of the largest and most complex driver of the whole suite. It handles all HID devices, and because there is a very wide variety of them, and because the USB HID specification isn’t simple, it needs to be this big. Currently, it handles USB mice, joysticks, gamepads, steering wheels keyboards, trackballs and digitizers. However, USB uses HID also for monitor controls, speaker controls, UPSs, LCDs and many other purposes. The monitor and speaker controls should be easy to add to the hid/input interface, but for the UPSs and LCDs it doesn’t make much sense. For this, the hiddev interface was designed. See Documentation/hid/hiddev.rst for more information about it. However, because the devices vary wildly, you might happen to have a device that doesn’t work well. In that case define DEBUG at the beginning of hid-core.c and send me the syslog traces. For embedded systems, for mice with broken HID descriptors and just any other use when the big usbhid wouldn’t be a good choice, there is the usbmouse driver. It handles USB mice only. It uses a simpler HIDBP protocol. This also means the mice must support this simpler protocol. Not all do. If you don’t have any strong reason to use this module, use usbhid instead. Much like usbmouse, this module talks to keyboards with a simplified HIDBP protocol. It’s smaller, but doesn’t support any extra special keys. Use usbhid instead if there isn’t any special reason to use this. This is driver for all flavors of pointing devices using PS/2 protocol, including Synaptics and ALPS touchpads, Intellimouse Explorer devices, Logitech PS/2 mice and so on. A driver for I-Force joysticks and wheels, both over USB and RS232. It includes Force Feedback support now, even though Immersion Corp. considers the protocol a trade secret and won’t disclose a word about it. You can test the joystick emulation with the jstest utility, available in the joystick package (see Introduction ). You can use blocking and nonblocking reads, and also select() on the /dev/input/eventX devices, and you’ll always get a whole number of input events on a read