Documentation/input/input.rst - linux-mtk - Git at Google


            
            .. include:: <isonum.txt>


            ============

            
            Introduction

            
            ============


            :Copyright: |copy| 1999-2001 Vojtech Pavlik <vojtech@ucw.cz> - Sponsored by SuSE


            Architecture

            
            ============


            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.


            The core of the input subsystem is the input module, which must be

            
            loaded before any other of the input modules - it serves as a way of

            
            communication between two groups of modules:


            Device drivers

            
            --------------


            These modules talk to the hardware (for example via USB), and provide

            
            events (keystrokes, mouse movements) to the input module.


            Event handlers

            
            --------------


            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.


            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 the

            
            kernel)::


            	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 mouse

            
            will 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 usually created automatically by the system. The commands

            
            to 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) and

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

            
            in-kernel consumers, as needed.


            evdev

            
            ~~~~~


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


            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 legacy

            
            range. If there are more than 32 input devices in a system, additional

            
            evdev nodes are created with minors starting with 256.


            keyboard

            
            ~~~~~~~~


            ``keyboard`` is in-kernel input handler and is a part of VT code. It

            
            consumes keyboard keystrokes and handles user input for VT consoles.


            mousedev

            
            ~~~~~~~~


            ``mousedev`` is a hack to make legacy programs that use mouse input

            
            work. It takes events from either mice or digitizers/tablets and makes

            
            a PS/2-style (a la /dev/psaux) mouse device available to the

            
            userland.


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


            CONFIG_INPUT_MOUSEDEV_SCREEN_[XY] in the kernel configuration are

            
            the size of your screen (in pixels) in XFree86. This is needed if you

            
            want to use your digitizer in X, because its movement is sent to X

            
            via a virtual PS/2 mouse and thus needs to be scaled

            
            accordingly. These values won't be used if you use a mouse only.


            Mousedev will generate either PS/2, ImPS/2 (Microsoft IntelliMouse) or

            
            ExplorerPS/2 (IntelliMouse Explorer) protocols, depending on what the

            
            program reading the data wishes. You can set GPM and X to any of

            
            these. You'll need ImPS/2 if you want to make use of a wheel on a USB

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

            
            above 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 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.txt

            
            for 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, it

            
            detects it appropriately.


            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.


            usbmouse

            
            ~~~~~~~~


            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.


            usbkbd

            
            ~~~~~~


            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.


            psmouse

            
            ~~~~~~~


            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.


            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 Immersion

            
            Corp. considers the protocol a trade secret and won't disclose a word

            
            about it.


            Verifying if it works

            
            =====================


            Typing a couple keys on the keyboard should be enough to check that

            
            a keyboard works and is correctly connected to the kernel keyboard

            
            driver.


            Doing a ``cat /dev/input/mouse0`` (c, 13, 32) will verify that a mouse

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

            
            events on a read. Their layout is::


                struct input_event {

            
            	    struct timeval time;

            
            	    unsigned short type;

            
            	    unsigned short code;

            
            	    unsigned int value;

            
                };


            ``time`` is the timestamp, it returns the time at which the event happened.

            
            Type is for example EV_REL for relative moment, EV_KEY for a keypress or

            
            release. 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 complete

            
            list is in include/uapi/linux/input-event-codes.h.


            ``value`` is the value the event carries. Either a relative change for

            
            EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for

            
            release, 1 for keypress and 2 for autorepeat.


            See :ref:`input-event-codes` for more information about various even codes.
	.. include:: <isonum.txt>

	============
	Introduction
	============

	:Copyright: \|copy\| 1999-2001 Vojtech Pavlik <vojtech@ucw.cz> - Sponsored by SuSE

	Architecture
	============

	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.

	The core of the input subsystem is the input module, which must be
	loaded before any other of the input modules - it serves as a way of
	communication between two groups of modules:

	Device drivers
	--------------

	These modules talk to the hardware (for example via USB), and provide
	events (keystrokes, mouse movements) to the input module.

	Event handlers
	--------------

	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.

	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 the
	kernel)::

	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 mouse
	will 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 usually created automatically by the system. The commands
	to 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) and
	XFree 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 and
	in-kernel consumers, as needed.

	evdev
	~~~~~

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

	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 legacy
	range. If there are more than 32 input devices in a system, additional
	evdev nodes are created with minors starting with 256.

	keyboard
	~~~~~~~~

	``keyboard`` is in-kernel input handler and is a part of VT code. It
	consumes keyboard keystrokes and handles user input for VT consoles.

	mousedev
	~~~~~~~~

	``mousedev`` is a hack to make legacy programs that use mouse input
	work. It takes events from either mice or digitizers/tablets and makes
	a PS/2-style (a la /dev/psaux) mouse device available to the
	userland.

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

	CONFIG_INPUT_MOUSEDEV_SCREEN_[XY] in the kernel configuration are
	the size of your screen (in pixels) in XFree86. This is needed if you
	want to use your digitizer in X, because its movement is sent to X
	via a virtual PS/2 mouse and thus needs to be scaled
	accordingly. These values won't be used if you use a mouse only.

	Mousedev will generate either PS/2, ImPS/2 (Microsoft IntelliMouse) or
	ExplorerPS/2 (IntelliMouse Explorer) protocols, depending on what the
	program reading the data wishes. You can set GPM and X to any of
	these. You'll need ImPS/2 if you want to make use of a wheel on a USB
	mouse 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 minors
	above 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 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.txt
	for 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, it
	detects it appropriately.

	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.

	usbmouse
	~~~~~~~~

	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.

	usbkbd
	~~~~~~

	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.

	psmouse
	~~~~~~~

	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.

	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 Immersion
	Corp. considers the protocol a trade secret and won't disclose a word
	about it.

	Verifying if it works
	=====================

	Typing a couple keys on the keyboard should be enough to check that
	a keyboard works and is correctly connected to the kernel keyboard
	driver.

	Doing a ``cat /dev/input/mouse0`` (c, 13, 32) will verify that a mouse
	is 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 input
	events on a read. Their layout is::

	struct input_event {
	struct timeval time;
	unsigned short type;
	unsigned short code;
	unsigned int value;
	};

	``time`` is the timestamp, it returns the time at which the event happened.
	Type is for example EV_REL for relative moment, EV_KEY for a keypress or
	release. 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 complete
	list is in include/uapi/linux/input-event-codes.h.

	``value`` is the value the event carries. Either a relative change for
	EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for
	release, 1 for keypress and 2 for autorepeat.

	See :ref:`input-event-codes` for more information about various even codes.