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 qDeviceq qstringq

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 qNameq qstringq

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 different ports. A list of currently plugged in devices and associated device names can be obtained by typing qcat /proc/bus/input/devicesq, the qNameq field is the value you want for this option. This option uses globbing.

Option qPhysq qstringq

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 qcat /proc/bus/input/devicesq, the qPhysq field is the value you want for this option. This option uses globbing.

Option q<map>Bitsq qbit specifierq

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 qcat /proc/bus/input/devicesq, and /usr/include/linux/input.h should contain the defines which declare what bits are what for each field.

Option qbustypeq qintegerq

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 qvendorq qintegerq

Specifies the vendor ID for the device you wish to use. This is either 0 (the default, matches anything), or the Vendor=<n> field in /proc/bus/input/devices for your device. This value should remain constant barring perhaps firmware updates to the device itself.

Option qversionq qintegerq

Specifies the version for the device you wish to use. This is either 0 (the default, matches anything), or the Version=<n> field in /proc/bus/input/devices for your device. This value should remain constant barring perhaps firmware updates to the device itself.

Option qproductq qintegerq

Specifies the product ID for the device you wish to use. This is either 0 (the default, matches anything), or the Product=<n> field in /proc/bus/input/devices for your device. This value should remain constant barring perhaps firmware updates to the device itself.

Option qPassq qintegerq

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.

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 q<axis>RelativeAxisMapq qnumberq

This remaps the axis specified to the specified valuator.

Option q<axis>RelativeAxisButtonsq qnumber"numberq

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.

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 q<axis>AbsoluteAxisMapq qnumberq

This remaps the axis specified to the specified valuator.

Option qAbsoluteScreenq qnumberq

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 qModeq q<mode>q

This selects the default mode for the device. Valid values are qabsoluteq and qrelativeq. This can be set at run time per actual device with the xinput utility.

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.

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 qXkbRulesq qrulesq

specifies which XKB rules file to use for interpreting the XkbModel, XkbLayout, XkbVariant, and XkbOptions settings. Default: "xorg" for most platforms, but "xfree98" for the Japanese PC-98 platforms.

Option qXkbModelq qmodelnameq

specifies the XKB keyboard model name. Default: "evdev".

Option qXkbLayoutq qlayoutnameq

specifies the XKB keyboard layout name. This is usually the country or language type of the keyboard. Default: "us".

Option qXkbVariantq qvariantsq

specifies the XKB keyboard variant components. These can be used to enhance the keyboard layout details. Default: not set.

Option qXkbOptionsq qoptionsq

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.