60-persistent-input.txt 4.5 KB

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