[1c48007] | 1 | Purpose of rules file:
|
---|
| 2 |
|
---|
| 3 | This rules file provides nonvolatile, unique names (in the form of symlinks)
|
---|
| 4 | for input devices that cooperate.
|
---|
| 5 |
|
---|
| 6 |
|
---|
| 7 | Description of rules:
|
---|
| 8 |
|
---|
| 9 | This file starts off with a few rules that make Udev skip the entire file if
|
---|
| 10 | the current uevent is not input related. If ACTION is not "add", or SUBSYSTEM
|
---|
| 11 | is not "input", or KERNEL (the device node) matches "input[0-9]*", then Udev
|
---|
| 12 | will GOTO the LABEL named "persistent_input_end", which is the last rule in
|
---|
| 13 | this file. (input[0-9]* uevents are skipped because they do not create device
|
---|
| 14 | nodes.)
|
---|
| 15 |
|
---|
| 16 | This type of "skip this list of rules if X" operation is done in both the
|
---|
| 17 | persistent input and persistent storage rules files. The reason is efficiency
|
---|
| 18 | -- if Udev had to go run the usb_id and/or path_id programs for non-input and
|
---|
| 19 | non-storage rules, those rules would take much longer to process for no good
|
---|
| 20 | reason.
|
---|
| 21 |
|
---|
| 22 |
|
---|
| 23 | First in this file is a set of rules for by-ID style symlinks. These attempt
|
---|
| 24 | to uniquely identify a device based on its serial number, but there are some
|
---|
| 25 | issues with this. Many USB manufacturers do not provide a unique serial number
|
---|
| 26 | for each device -- for instance, my Microsoft Intellimouse Optical has a USB
|
---|
| 27 | serial number of "Microsoft_Microsoft_IntelliMouse_Optical". This kind of
|
---|
| 28 | nonsensical "serial number" means that if you plug in two Intellimouse Optical
|
---|
| 29 | devices, they will both get the same by-id symlink, and the device that the
|
---|
| 30 | symlink points to will be random. This defeats the purpose of by-ID symlinks.
|
---|
| 31 | (However, I believe this behavior is technically valid according to the USB
|
---|
| 32 | standard. I believe it is not recommended, though.)
|
---|
| 33 |
|
---|
| 34 | Anyway, first in the by-ID rules, we have a rule that runs for any (input)
|
---|
| 35 | device hanging anywhere off a USB bus. It uses the IMPORT{program} option to
|
---|
| 36 | run the "/lib/udev/usb_id -x" program. usb_id looks at the environment to find
|
---|
| 37 | out which device to look at, generates a list of environment-variable VAR=value
|
---|
| 38 | pairs, and prints them. Udev stores this output away while the process is
|
---|
| 39 | running. After the process exits, Udev modifies the current environment to
|
---|
| 40 | include the VARs that usb_id printed. (It assigns the "value"s that usb_id
|
---|
| 41 | printed to each of those VARs.) Specifically, usb_id prints ID_VENDOR,
|
---|
| 42 | ID_MODEL, ID_REVISION, ID_SERIAL, ID_TYPE, and ID_BUS (at least in the case of
|
---|
| 43 | the aforementioned USB optical mouse). These variable names will all be set in
|
---|
| 44 | the environment.
|
---|
| 45 |
|
---|
| 46 | Then, we have a set of rules to set ID_CLASS for various types of devices. The
|
---|
| 47 | rules first check for a "usb"-bus device that has a "bInterfaceClass" of 03 and
|
---|
| 48 | a "bInterfaceProtocol" of 01. If the interface class is 03, this is an HID
|
---|
| 49 | device. If the protocol is 01, it's a keyboard device. So we set ID_CLASS to
|
---|
| 50 | "kbd". The next rule checks whether the interface protocol is 02, and if so,
|
---|
| 51 | sets ID_CLASS to "mouse" (HID devices with a protocol of 02 are mice).
|
---|
| 52 |
|
---|
| 53 | Any input device that the "pcspkr" driver claims must be a speaker. Any input
|
---|
| 54 | device that the "atkbd" driver claims must be a keyboard. Any input device
|
---|
| 55 | that the "psmouse" driver claims must be a mouse. If there's a sysfs attribute
|
---|
| 56 | named "name", whose contents contain "dvb", "DVB", or " IR ", then we set
|
---|
| 57 | ID_CLASS to "ir".
|
---|
| 58 |
|
---|
| 59 | Then, we have a rule to search the tree and find the first parent that has a
|
---|
| 60 | modalias. If that modalias matches the big long ugly string in the rules file,
|
---|
| 61 | we assume this is a joystick device, and set ID_CLASS appropriately. (This
|
---|
| 62 | parent should be the kobject for the joystick device itself. The reason we
|
---|
| 63 | search the tree is that the current uevent is for a device node, not the
|
---|
| 64 | physical joystick device.)
|
---|
| 65 |
|
---|
| 66 | Once the ID_CLASS variable is set properly, we have one more modification to
|
---|
| 67 | perform: if the ID_SERIAL variable was not set at all by the usb_id program, we
|
---|
| 68 | set it to "noserial".
|
---|
| 69 |
|
---|
| 70 | Now that all the environment variables are set up properly, we start generating
|
---|
| 71 | the by-ID symlinks in /dev/input/by-id/. If the current device node's name
|
---|
| 72 | starts with "event", we add "event" into the symlink name. Otherwise, we don't
|
---|
| 73 | add anything for mice. (Other device types don't get a persistent by-ID
|
---|
| 74 | symlink.)
|
---|
| 75 |
|
---|
| 76 |
|
---|
| 77 | Next, we create by-path symlinks. The /lib/udev/path_id program takes the path
|
---|
| 78 | of the device as an argument, and prints out "ID_PATH=string", where "string"
|
---|
| 79 | is the "shortest physical path" to the device. We import this value into the
|
---|
| 80 | environment.
|
---|
| 81 |
|
---|
| 82 | If the path is non-empty, and the device node name starts with "mouse" or
|
---|
| 83 | "event", we add a by-path symlink based on the path and the device class (and
|
---|
| 84 | we also add "event" if it's an event device). This symlink should be stable as
|
---|
| 85 | long as the device never moves to a different port.
|
---|
| 86 |
|
---|