EVDEV(4) EVDEV(4)
NAME
evdev - Generic Linux input driver
SYNOPSIS
Section "InputDevice"
Identifier "devname"
Driver "evdev"
Option "Device" "devpath"
...
EndSection
DESCRIPTION
evdev is an Xorg input driver for Linux's generic event devices. It
therefore supports all input devices that the kernel knows about,
including most mice and keyboards.
The evdev driver can serve as both a pointer and a keyboard input
device, and may be used as both the core keyboard and the core pointer.
Multiple input devices are supported by multiple instances of this
driver, with one Load directive for evdev in the Module section of your
xorg.conf for each input device that will use this driver.
SUPPORTED HARDWARE
In general, any input device that the kernel has a driver for can be
accessed through the evdev driver. See the Linux kernel documentation
for a complete list.
CONFIGURATION DETAILS
Please refer to xorg.conf(5) for general configuration details and for
options that can be used with all input drivers. This section only
covers configuration details specific to this driver.
BASIC CONFIGURATIONS
Most users of this driver will probably be quite happy with the follow-
ing for all QWERTY keyboards:
Section "InputDevice"
Identifier "keyboard"
Driver "evdev"
Option "evBits" "+1"
Option "keyBits" "~1-255 ~352-511"
Option "Pass" "3"
...
EndSection
And the following for all mice:
Section "InputDevice"
Identifier "mouse"
Driver "evdev"
Option "evBits" "+1-2"
Option "keyBits" "~272-287"
Option "relBits" "~0-2 ~6 ~8"
Option "Pass" "3"
...
EndSection
To understand what those Bits options do, or for more complex configu-
rations, please see ADVANCED OPTIONS below.
ADVANCED OPTIONS
DEVICE SPECIFICATION
For this section you'll want to have knowledge of glob (7) and our evil
BIT MATCHING SPECIFICATION stuff.
The following driver Options control what devices are accepted:
Option "Device" "string"
Specifies the device note through which the device can be
accessed. At this time ONLY /dev/input/event<N>, where <N> is
an integer, are matched against this this field.
This option uses globbing.
Please note that use of this option is strongly discouraged.
Option "Name" "string"
Specifies the device name for the device you wish to use.
The device name is generally the only consistent identifier for
devices that are commonly unplugged and plugged back into dif-
ferent ports.
A list of currently plugged in devices and associated device
names can be obtained by typing "cat /proc/bus/input/devices",
the "Name" field is the value you want for this option.
This option uses globbing.
Option "Phys" "string"
Specifies the device phys string for the device you wish to use.
The phys string is generally consistant to the USB port a device
is plugged into.
A list of currently plugged in devices and associated device
names can be obtained by typing "cat /proc/bus/input/devices",
the "Phys" field is the value you want for this option.
This option uses globbing.
Option "<map>Bits" "bit specifier"
Specifies device capability bits which must be set, possibly
set, or unset.
<map>Bits: Where map is one of ev, key, rel, abs, msc, led, snd,
or ff.
The bit specifier format is a string consisting of +<n>, -<n>,
and ~<n> space sepirated specifiers, where <n> is a positive
integer or integer range. (The latter given in the format of
2-6.)
+ specifies bits which must be set.
- specifies bits which must not be set.
~ is a little more complex, it specifies that at least one of
the bits given with ~ for the field in question must be set, but
it doesn't matter how many or which of the bits. (It is actually
the most useful of the 3 specifiers.)
As an example '+0 +3 -1-2 ~5-10', requires bits 0 and 3 be set,
bits 1 and 2 to not be set, and at least one bit in the range of
5 to 10 be set.
An annoyingly formatted set of bitmasks for your devices can be
obtained by typing "cat /proc/bus/input/devices", and
/usr/include/linux/input.h should contain the defines which
declare what bits are what for each field.
Option "bustype" "integer"
Specifies the bus ID for the device you wish to use.
This is either 0 (the default, matches anything), or the Bus=<n>
field in /proc/bus/input/devices for your device.
This value depends on what type of bus your device is connected
to.
Option "vendor" "integer"
Specifies the vendor ID for the device you wish to use.
This is either 0 (the default, matches anything), or the Ven-
dor=<n> field in /proc/bus/input/devices for your device.
This value should remain constant barring perhaps firmware
updates to the device itself.
Option "version" "integer"
Specifies the version for the device you wish to use.
This is either 0 (the default, matches anything), or the Ver-
sion=<n> field in /proc/bus/input/devices for your device.
This value should remain constant barring perhaps firmware
updates to the device itself.
Option "product" "integer"
Specifies the product ID for the device you wish to use.
This is either 0 (the default, matches anything), or the Prod-
uct=<n> field in /proc/bus/input/devices for your device.
This value should remain constant barring perhaps firmware
updates to the device itself.
Option "Pass" "integer"
Specifies the order in which evdev will scan for devices.
This is in the range of 0 to 3, and is used for the case where
more then one evdev inputsection matches the same device.
An inputsection with a lower pass number will always beat out
one with a higher pass number. Order when both sections are the
same number is undefined.
The default is 0.
RELATIVE AXIS CONFIGURATION
The relative axis portion of this driver handle all reported relative
axies.
The axies are named X, Y, Z, RX, RY, RZ, HWHEEL, DIAL, WHEEL, MISC, 10,
11, 12, 13, 14, and 15.
The axies are reported to X as valuators, with the default mapping of
axies to valuators being the first axies found to the first valuator,
the second found to the second valuator, and so on, so that if you have
axies X, Y, HWHEEL, and WHEEL, you would have X=0, Y=1, HWHEEL=2,
WHEEL=3.
If the driver is reporting core events, valuators 0 and 1 are always
mapped to x and y coordinates, respectively.
The following driver Options control the relative axis portion of the
driver:
Option "<axis>RelativeAxisMap" "number"
This remaps the axis specified to the specified valuator.
Option "<axis>RelativeAxisButtons" "number number"
This remaps the axis specified to the specified buttons.
Note that the physical buttons are always remapped around 'fake'
buttons created by this option, so that if you have physical
buttons 1 2 3 4 5, and map the Wheel axis to buttons 4 5, you
get buttons 1 2 3 4 5 6 7, with buttons 6 and 7 being physical
buttons 4 and 5.
ABSOLUTE AXIS CONFIGURATION
The relative axis portion of this driver handle all reported relative
axies.
The axies are named X, Y, Z, RX, RY, RZ, THROTTLE, RUDDER, WHEEL, GAS,
BREAK, <11-15>, HAT0X, HAT0Y, HAT1X, HAT1Y, HAT2X, HAT2Y, HAT3X, HAT3Y,
PRESSURE, TILT_X, TILT_Y, TOOL_WIDTH, VOLUME, <29-39>, MISC, <41-62>.
The axies are reported to X as valuators, with the default mapping of
axies to valuators being the first axies found to the first valuator,
the second found to the second valuator, and so on, so that if you have
axies X, Y, TILT_X, and TILT_Y, you would have X=0, Y=1, TILT_X=2,
TILT_Y=3.
If the driver is reporting core events, valuators 0 and 1 are always
mapped to x and y coordinates, respectively.
The following driver Options control the relative axis portion of the
driver:
Option "<axis>AbsoluteAxisMap" "number"
This remaps the axis specified to the specified valuator.
Option "AbsoluteScreen" "number"
This binds the device to a specific screen, scaling it to the
coordinate space of that screen.
The number can either be -1, or a valid screen number.
If -1 or if in relative mode no scaling or screen fixing is
done.
This is of most use for digitizers, where the screen and the
input device are the same surface.
Option "Mode" "<mode>"
This selects the default mode for the device.
Valid values are "absolute" and "relative".
This can be set at run time per actual device with the xinput
utility.
BUTTON CONFIGURATION
At the moment, the button portion of this driver only handles buttons
reported as mouse buttons, that is from BTN_MOUSE to BTN_JOYSTICK - 1.
At this time there are no configuration options for buttens.
KEYBOARD CONFIGURATION
The keyboard portion of this driver handles all keys reported and
requires XKB support.
The following driver Options control the relative axis portion of the
driver:
Option "XkbRules" "rules"
specifies which XKB rules file to use for interpreting the Xkb-
Model, XkbLayout, XkbVariant, and XkbOptions settings. Default:
"xorg" for most platforms, but "xfree98" for the Japanese PC-98
platforms.
Option "XkbModel" "modelname"
specifies the XKB keyboard model name. Default: "evdev".
Option "XkbLayout" "layoutname"
specifies the XKB keyboard layout name. This is usually the
country or language type of the keyboard. Default: "us".
Option "XkbVariant" "variants"
specifies the XKB keyboard variant components. These can be
used to enhance the keyboard layout details. Default: not set.
Option "XkbOptions" "options"
specifies the XKB keyboard option components. These can be used
to enhance the keyboard behaviour. Default: not set.
Some other XKB-related options are available, but they are incompatible
with the ones listed above and are not recommended, so they are not
documented here.
AUTHORS
Kristian Hgsberg.
Zephaniah E. Hull.
SEE ALSO
Xorg(1), xorg.conf(5), xorgconfig(1), Xserver(1), X(7), README.mouse.
X Version 11 xf86-input-evdev 1.1.2 EVDEV(4)
