Something went wrong. Try again.
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Something went wrong. Try again.
9.1 kB · 281 lines
at master
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282.. include:: <isonum.txt>
============Introduction============
:Copyright: |copy| 1999-2001 Vojtech Pavlik <vojtech@ucw.cz> - Sponsored by SuSE
Architecture============
Input subsystem is a collection of drivers that is designed to supportall input devices under Linux. Most of the drivers reside indrivers/input, although quite a few live in drivers/hid anddrivers/platform.
The core of the input subsystem is the input module, which must beloaded before any other of the input modules - it serves as a way ofcommunication between two groups of modules:
Device drivers--------------
These modules talk to the hardware (for example via USB), and provideevents (keystrokes, mouse movements) to the input module.
Event handlers--------------
These modules get events from input core and pass them where neededvia various interfaces - keystrokes to the kernel, mouse movements viaa simulated PS/2 interface to GPM and X, and so on.
Simple Usage============
For the most usual configuration, with one USB mouse and one USB keyboard,you'll have to load the following modules (or have them built in to thekernel)::
input mousedev usbcore uhci_hcd or ohci_hcd or ehci_hcd usbhid hid_generic
After this, the USB keyboard will work straight away, and the USB mousewill be available as a character device on major 13, minor 63::
crw-r--r-- 1 root root 13, 63 Mar 28 22:45 mice
This device is usually created automatically by the system. The commandsto create it by hand are::
cd /dev mkdir input mknod input/mice c 13 63
After that you have to point GPM (the textmode mouse cut&paste tool) andXFree to this device to use it - GPM should be called like::
gpm -t ps2 -m /dev/input/mice
And in X::
Section "Pointer" Protocol "ImPS/2" Device "/dev/input/mice" ZAxisMapping 4 5 EndSection
When you do all of the above, you can use your USB mouse and keyboard.
Detailed Description====================
Event handlers--------------
Event handlers distribute the events from the devices to userspace andin-kernel consumers, as needed.
evdev~~~~~
``evdev`` is the generic input event interface. It passes the eventsgenerated in the kernel straight to the program, with timestamps. Theevent codes are the same on all architectures and are hardwareindependent.
This is the preferred interface for userspace to consume userinput, and all clients are encouraged to use it.
See :ref:`event-interface` for notes on API.
The devices are in /dev/input::
crw-r--r-- 1 root root 13, 64 Apr 1 10:49 event0 crw-r--r-- 1 root root 13, 65 Apr 1 10:50 event1 crw-r--r-- 1 root root 13, 66 Apr 1 10:50 event2 crw-r--r-- 1 root root 13, 67 Apr 1 10:50 event3 ...
There are two ranges of minors: 64 through 95 is the static legacyrange. If there are more than 32 input devices in a system, additionalevdev nodes are created with minors starting with 256.
keyboard~~~~~~~~
``keyboard`` is in-kernel input handler and is a part of VT code. Itconsumes keyboard keystrokes and handles user input for VT consoles.
mousedev~~~~~~~~
``mousedev`` is a hack to make legacy programs that use mouse inputwork. It takes events from either mice or digitizers/tablets and makesa PS/2-style (a la /dev/psaux) mouse device available to theuserland.
Mousedev devices in /dev/input (as shown above) are::
crw-r--r-- 1 root root 13, 32 Mar 28 22:45 mouse0 crw-r--r-- 1 root root 13, 33 Mar 29 00:41 mouse1 crw-r--r-- 1 root root 13, 34 Mar 29 00:41 mouse2 crw-r--r-- 1 root root 13, 35 Apr 1 10:50 mouse3 ... ... crw-r--r-- 1 root root 13, 62 Apr 1 10:50 mouse30 crw-r--r-- 1 root root 13, 63 Apr 1 10:50 mice
Each ``mouse`` device is assigned to a single mouse or digitizer, exceptthe last one - ``mice``. This single character device is shared by allmice and digitizers, and even if none are connected, the device ispresent. This is useful for hotplugging USB mice, so that older programsthat do not handle hotplug can open the device even when no mice arepresent.
CONFIG_INPUT_MOUSEDEV_SCREEN_[XY] in the kernel configuration arethe size of your screen (in pixels) in XFree86. This is needed if youwant to use your digitizer in X, because its movement is sent to Xvia a virtual PS/2 mouse and thus needs to be scaledaccordingly. These values won't be used if you use a mouse only.
Mousedev will generate either PS/2, ImPS/2 (Microsoft IntelliMouse) orExplorerPS/2 (IntelliMouse Explorer) protocols, depending on what theprogram reading the data wishes. You can set GPM and X to any ofthese. You'll need ImPS/2 if you want to make use of a wheel on a USBmouse and ExplorerPS/2 if you want to use extra (up to 5) buttons.
joydev~~~~~~
``joydev`` implements v0.x and v1.x Linux joystick API. See:ref:`joystick-api` for details.
As soon as any joystick is connected, it can be accessed in /dev/input on::
crw-r--r-- 1 root root 13, 0 Apr 1 10:50 js0 crw-r--r-- 1 root root 13, 1 Apr 1 10:50 js1 crw-r--r-- 1 root root 13, 2 Apr 1 10:50 js2 crw-r--r-- 1 root root 13, 3 Apr 1 10:50 js3 ...
And so on up to js31 in legacy range, and additional nodes with minorsabove 256 if there are more joystick devices.
Device drivers--------------
Device drivers are the modules that generate events.
hid-generic~~~~~~~~~~~
``hid-generic`` is one of the largest and most complex driver of thewhole suite. It handles all HID devices, and because there is a verywide variety of them, and because the USB HID specification isn'tsimple, 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/inputinterface, but for the UPSs and LCDs it doesn't make much sense. For this,the hiddev interface was designed. See Documentation/hid/hiddev.rstfor more information about it.
The usage of the usbhid module is very simple, it takes no parameters,detects everything automatically and when a HID device is inserted, itdetects it appropriately.
However, because the devices vary wildly, you might happen to have adevice that doesn't work well. In that case #define DEBUG at the beginningof hid-core.c and send me the syslog traces.
usbmouse~~~~~~~~
For embedded systems, for mice with broken HID descriptors and just anyother use when the big usbhid wouldn't be a good choice, there is theusbmouse driver. It handles USB mice only. It uses a simpler HIDBPprotocol. This also means the mice must support this simpler protocol. Notall do. If you don't have any strong reason to use this module, use usbhidinstead.
usbkbd~~~~~~
Much like usbmouse, this module talks to keyboards with a simplifiedHIDBP 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.
psmouse~~~~~~~
This is driver for all flavors of pointing devices using PS/2protocol, including Synaptics and ALPS touchpads, IntellimouseExplorer devices, Logitech PS/2 mice and so on.
atkbd~~~~~
This is driver for PS/2 (AT) keyboards.
iforce~~~~~~
A driver for I-Force joysticks and wheels, both over USB and RS232.It includes Force Feedback support now, even though ImmersionCorp. considers the protocol a trade secret and won't disclose a wordabout it.
Verifying if it works=====================
Typing a couple keys on the keyboard should be enough to check thata keyboard works and is correctly connected to the kernel keyboarddriver.
Doing a ``cat /dev/input/mouse0`` (c, 13, 32) will verify that a mouseis also emulated; characters should appear if you move it.
You can test the joystick emulation with the ``jstest`` utility,available in the joystick package (see :ref:`joystick-doc`).
You can test the event devices with the ``evtest`` utility.
.. _event-interface:
Event interface===============
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 inputevents on a read. Their layout is::
struct input_event { struct timeval time; unsigned short type; unsigned short code; int value; };
``time`` is the timestamp, it returns the time at which the event happened.Type is for example EV_REL for relative movement, EV_KEY for a keypress orrelease. More types are defined in include/uapi/linux/input-event-codes.h.
``code`` is event code, for example REL_X or KEY_BACKSPACE, again a completelist is in include/uapi/linux/input-event-codes.h.
``value`` is the value the event carries. Either a relative change forEV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY forrelease, 1 for keypress and 2 for autorepeat.
See :ref:`input-event-codes` for more information about various event codes.