Differences between revisions 11 and 12
Revision 11 as of 2009-12-17 11:31:47
Size: 6883
Editor: pD9EB45A7
Revision 12 as of 2010-01-03 20:32:38
Size: 6978
Editor: pD9EB63DC
Comment: add idProduct migration guide
Deletions are marked like this. Additions are marked like this.
Line 142: Line 142:
 || `<match key="info.product" string="ProductName">` || `ATTRS{idProduct}=="ProductName"` ||


Unless xorg.conf has manual configuration, uses udev for detecting input devices, and udev properties for configuring them. This is what happens in detail:

  1. A hardware input device is present at boot, or gets hotplugged.
  2. The kernel detects this, and creates a new "input" device (e. g. /sys/class/input/input3) and an "event" interface for it (/sys/class/input/event3 and a device node /dev/input/event3) which you can use to talk to the input device, see /usr/include/linux/input.h.

  3. udev picks up the "add" event and the new device. /lib/udev/rules.d/60-persistent-input.rules calls /lib/udev/input_id on it, which detects the class of the device (mouse, touchpad, etc.) and attaches some properties to it:

     $ /lib/udev/input_id /class/input/event4
     $ /lib/udev/input_id /class/input/event14
  4. udev applies additional rules shipped by the packages (/lib/udev/rules.d/*xorg*), which assign an X11 driver and device specific properties like keyboard layout or touchpad quirks:

     P: /devices/platform/i8042/serio0/input/input4/event4
     E: DEVNAME=/dev/input/event4
     E: ID_INPUT=1
     E: ID_INPUT_KEY=1
     E: XKBMODEL=pc105
     E: XKBLAYOUT=de
     E: XKBVARIANT=nodeadkeys
     E: x11_driver=evdev
     P: /devices/platform/i8042/serio1/input/input14/event14
     N: input/event14
     E: DEVNAME=/dev/input/event14
     E: ID_INPUT=1
     E: x11_driver=synaptics
     E: x11_options.JumpyCursorThreshold=20
  5. picks up the add event or detects existing devices at startup, and adds it to its configuration:
     (II) config/udev: Adding input device "AT Translated Set 2 keyboard" (/dev/input/event4)
     (**) "AT Translated Set 2 keyboard": always reports core events
     (**) "AT Translated Set 2 keyboard": Device: "/dev/input/event4"
     (II) "AT Translated Set 2 keyboard": Found keys
     (II) "AT Translated Set 2 keyboard": Configuring as keyboard
     (II) XINPUT: Adding extended input device ""AT Translated Set 2 keyoard"" (type: KEYBOARD)
     (**) Option "xkb_rules" "evdev"
     (**) Option "xkb_model" "pc105"
     (**) Option "xkb_layout" "de"
     (**) Option "xkb_variant" "nodeadkeys"

Udev rules

Please see the udev manpage (man udev) for general documentation about udev rules.

Device classification

As shown above, udev itself already classifies the input devices with input_id. Existing flags are:


    All input devices have this flag.


    Touchscreens and tables have this flag as well, since by the type of events they can produce they act as a mouse.





    Keyboards have this, but also things like lid switches which have just a few buttons


Driver assignment

Most input devices like simple mice, keyboards, lid switches, etc. are supported by the general "evdev" input driver, so /lib/udev/rules.d/65-xorg-evdev.rules sets ENV{x11_driver}="evdev" by default.

Later rules (i. e. with a prefix higher than 65) can change the property to use a different driver. 66-xorg-synaptics.rules is a prominent example for using the "synaptics" driver for touchpads and setting ENV{x11_driver}="synaptics" for devices which have ID_INPUT_TOUCHPAD.

Keyboard layout

In Ubuntu, the system default keyboard layout is configured in /etc/default/console-setup, in particular the XKB* fields. 64-xorg-xkb.rules greps those variables out of there and attaches them to all devices which have ID_INPUT_KEY, so that they end up as udev properties like shown above (XKBLAYOUT=de).

Driver/device options

In general, an udev property

  •  ENV{}="value"

will achieve the same as specifying

  •  Option "name" "value"

in xorg.conf for that particular device. However, unlike xorg.conf, udev rules are distributed over many files and thus can be shipped by the packages that they affect, and they are much more dynamic: for example, they can check for a particular machine brand/type, call external programs to check state, etc.

66-xorg-synaptics.rules shows how to define machine specific options:

  •  ATTR{[dmi/id]product_name}=="Inspiron 1011|Inspiron 1012", \
       ENV{x11_options.JumpyCursorThreshold}="90", \

[dmi/id]product_name means that the value is read from /sys/class/dmi/id/product_name, which has all the DMI data.

Note that this rule only gets executed for devices which have ID_INPUT_TOUCHPAD, which is tested earlier on in the file. If you want to define your own rule file (e. g. /etc/udev/rules.d/90-xorg-local.rules), you should explicitly add this test, and of course you don't need to check the machine name:

  •  ENV{ID_INPUT_TOUCHPAD}=="1", ENV{x11_options.AreaBottomEdge}="5000"

Migration from hal FDI files

Up to Ubuntu 9.10, used hal and fdi files for input hotplugging and configuration. The distribution-provided fdi files have all been replaced with udev rules already, but if you created local custom fdi files, you need to translate them into udev rules which follow the existing structure of e. g. /udev/rules.d/66-xorg-synaptics.rules. You should create them in /etc/udev/rules.d/90-xorg-local.rules, so that they are not affected by packages and overwrite the distribution default settings.

This is how the concepts translate:

  • hal fdi rule element

    corresponding udev rule element

    <match key="info.capabilities" contains="input.mouse">


    <match key="info.product" string="ProductName">


    <merge key="input.x11_driver" type="string">vmmouse</merge>


    <merge key="input.x11_options.VertTwoFingerScroll" type="string">true</merge>


    <append key="info.callouts.add" type="strlist">hal-setup-wacom</append>

    RUN+="/usr/lib/wacom/setup-wacom %p"

So, if you previously used a custom fdi file like

  •  <?xml version="1.0" encoding="ISO-8859-1"?>
     <deviceinfo version="0.2">
         <match key="info.capabilities" contains="input.mouse">
           <merge key="input.x11_driver" type="string">vmmouse`/merge>

This would now become the following udev rule:

  •  ENV{ID_INPUT_MOUSE}==1, ENV{x11_driver}="vmmouse"

X/InputConfiguration (last edited 2010-04-13 19:25:32 by 80-219-113-108)