So what is udev you might ask, well here is what aptitude says:

udev is a program which dynamically creates and removes device nodes from /dev/. It responds to /sbin/hotplug device events and requires a 2.6 kernel.

Well that mighty fine but why would I want to use it?

My interest in udev is caused by the fact that I have a Medion MD 41217 digitiser (It's actually made by Aiptek). However when plugged into my computer the output from the driver goes to /dev/input/eventX where X is determined by the number of other devices that generate input events, as a result it has no fixed name.
This is a big problem as the Aiptek X11 driver has to be given the name of the device (for some odd reason X11 fails to start if the aiptek driver fails even through it is't the "CorePointer", this makes it an even bigger problem).
I have a similar but less annoying problem with my flash card reader and my USB hard disk as they both use /dev/sdX.
Luckily udev can solve this problem by allowing you to create symbolic links that always points to the right device.
This is achieved by matching device dependent information, for instance my digitiser has BUS="usb" and DRIVER="aiptek".

Before I present my summary of what I did here is a couple of useful links:
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
http://www.reactivated.net/udevrules.php

  • You have to use a kernel 2.6.x (I used 2.6.10 but some older kernels can be used as well), and is has to be configued with CONFIG_HOTPLUG.
  • You have to have udev installed, it is apt-get'able at least when using unstable (I believe it is in testing as well), it will also install the hotplug package.
  • Create an rule file that determine the mapping of the devices, I used /etc/udev/rules.d/00myRules.rules as I wanted my rules to take precedence over any default rules.
  • Populate the rules file with rules, the rule for my digitiser looks like this
    #digitiser
    BUS="usb", DRIVER="aiptek", NAME="input/%k", SYMLINK="input/aiptek"

    And has the following meaning. 1. line is just a comment, 2. line says when something that uses the aiptek kernel driver is connected to the USB bus, create a device with the normal kernel NAME (="input/%k") and create a symbolic link /dev/input/aiptek that points to this device.
You may wonder where i got the id strings from, its simple i used udevinfo -ap /sys/class/input/event1 which among other things returned:
  looking at the device chain at '/sys/devices/pci0000:00/0000:00:0f.0/usb2/2-1/2-1.3/2-1.3:1.0':
    BUS="usb"
    ID="2-1.3:1.0"
    DRIVER="aiptek"
    SYSFS{bAlternateSetting}=" 0"
    SYSFS{bInterfaceClass}="03"
    SYSFS{bInterfaceNumber}="00"
    SYSFS{bInterfaceProtocol}="00"
    SYSFS{bInterfaceSubClass}="00"
    SYSFS{bNumEndpoints}="01"
    SYSFS{coordinate_mode}="absolute"
    SYSFS{delay}="400"
    SYSFS{detach_state}="0"
    SYSFS{diagnostic}="no errors"
    SYSFS{event_count}="0"
    SYSFS{execute}="Write anything to this file to program your tablet."
    SYSFS{firmware_code}="0105"
    SYSFS{input_path}="/dev/input/event1"
    SYSFS{jitter}="50"
    SYSFS{model_code}="0x00c9"
    SYSFS{mouse_left}="left"
    SYSFS{mouse_middle}="middle"
    SYSFS{mouse_right}="right"
    SYSFS{odm_code}="0x0000"
    SYSFS{pointer_mode}="either"
    SYSFS{product}="USB Tablet Series Version 1.05"
    SYSFS{product_id}="0x0010"
    SYSFS{proximity_timeout}="200"
    SYSFS{size}="6000x4500"
    SYSFS{stylus_lower}="lower"
    SYSFS{stylus_upper}="upper"
    SYSFS{tool_mode}="pen"
    SYSFS{vendor}="AIPTEK International Inc."
    SYSFS{vendor_id}="0x08ca"
    SYSFS{wheel}="0"
    SYSFS{xtilt}="disable"
    SYSFS{ytilt}="disable"

The exact path to your favourite device may differ but it is located somewhere in /sys/.
One important note!!! It seems to be very important only to specify a path containing a "dev" file to udevinfo, otherwise you may find information that is't available to udev!
This happened to me as the apitek driver i kernel 2.6.10 had a bug and failed to create som symlinks in the /sys/ filesystem. Version 1.8 of the driver fixes this problem.
On my system only /sys/block/* and /sys/class/* contains "dev" files, you may use something like "find /sys/ -name "dev"" to search for locations containing "dev" files.