hiddev.rst 9.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251
  1. ================================================
  2. Care and feeding of your Human Interface Devices
  3. ================================================
  4. Introduction
  5. ============
  6. In addition to the normal input type HID devices, USB also uses the
  7. human interface device protocols for things that are not really human
  8. interfaces, but have similar sorts of communication needs. The two big
  9. examples for this are power devices (especially uninterruptable power
  10. supplies) and monitor control on higher end monitors.
  11. To support these disparate requirements, the Linux USB system provides
  12. HID events to two separate interfaces:
  13. * the input subsystem, which converts HID events into normal input
  14. device interfaces (such as keyboard, mouse and joystick) and a
  15. normalised event interface - see Documentation/input/input.rst
  16. * the hiddev interface, which provides fairly raw HID events
  17. The data flow for a HID event produced by a device is something like
  18. the following::
  19. usb.c ---> hid-core.c ----> hid-input.c ----> [keyboard/mouse/joystick/event]
  20. |
  21. |
  22. --> hiddev.c ----> POWER / MONITOR CONTROL
  23. In addition, other subsystems (apart from USB) can potentially feed
  24. events into the input subsystem, but these have no effect on the HID
  25. device interface.
  26. Using the HID Device Interface
  27. ==============================
  28. The hiddev interface is a char interface using the normal USB major,
  29. with the minor numbers starting at 96 and finishing at 111. Therefore,
  30. you need the following commands::
  31. mknod /dev/usb/hiddev0 c 180 96
  32. mknod /dev/usb/hiddev1 c 180 97
  33. mknod /dev/usb/hiddev2 c 180 98
  34. mknod /dev/usb/hiddev3 c 180 99
  35. mknod /dev/usb/hiddev4 c 180 100
  36. mknod /dev/usb/hiddev5 c 180 101
  37. mknod /dev/usb/hiddev6 c 180 102
  38. mknod /dev/usb/hiddev7 c 180 103
  39. mknod /dev/usb/hiddev8 c 180 104
  40. mknod /dev/usb/hiddev9 c 180 105
  41. mknod /dev/usb/hiddev10 c 180 106
  42. mknod /dev/usb/hiddev11 c 180 107
  43. mknod /dev/usb/hiddev12 c 180 108
  44. mknod /dev/usb/hiddev13 c 180 109
  45. mknod /dev/usb/hiddev14 c 180 110
  46. mknod /dev/usb/hiddev15 c 180 111
  47. So you point your hiddev compliant user-space program at the correct
  48. interface for your device, and it all just works.
  49. Assuming that you have a hiddev compliant user-space program, of
  50. course. If you need to write one, read on.
  51. The HIDDEV API
  52. ==============
  53. This description should be read in conjunction with the HID
  54. specification, freely available from https://www.usb.org, and
  55. conveniently linked of http://www.linux-usb.org.
  56. The hiddev API uses a read() interface, and a set of ioctl() calls.
  57. HID devices exchange data with the host computer using data
  58. bundles called "reports". Each report is divided into "fields",
  59. each of which can have one or more "usages". In the hid-core,
  60. each one of these usages has a single signed 32-bit value.
  61. read():
  62. -------
  63. This is the event interface. When the HID device's state changes,
  64. it performs an interrupt transfer containing a report which contains
  65. the changed value. The hid-core.c module parses the report, and
  66. returns to hiddev.c the individual usages that have changed within
  67. the report. In its basic mode, the hiddev will make these individual
  68. usage changes available to the reader using a struct hiddev_event::
  69. struct hiddev_event {
  70. unsigned hid;
  71. signed int value;
  72. };
  73. containing the HID usage identifier for the status that changed, and
  74. the value that it was changed to. Note that the structure is defined
  75. within <linux/hiddev.h>, along with some other useful #defines and
  76. structures. The HID usage identifier is a composite of the HID usage
  77. page shifted to the 16 high order bits ORed with the usage code. The
  78. behavior of the read() function can be modified using the HIDIOCSFLAG
  79. ioctl() described below.
  80. ioctl():
  81. --------
  82. This is the control interface. There are a number of controls:
  83. HIDIOCGVERSION
  84. - int (read)
  85. Gets the version code out of the hiddev driver.
  86. HIDIOCAPPLICATION
  87. - (none)
  88. This ioctl call returns the HID application usage associated with the
  89. HID device. The third argument to ioctl() specifies which application
  90. index to get. This is useful when the device has more than one
  91. application collection. If the index is invalid (greater or equal to
  92. the number of application collections this device has) the ioctl
  93. returns -1. You can find out beforehand how many application
  94. collections the device has from the num_applications field from the
  95. hiddev_devinfo structure.
  96. HIDIOCGCOLLECTIONINFO
  97. - struct hiddev_collection_info (read/write)
  98. This returns a superset of the information above, providing not only
  99. application collections, but all the collections the device has. It
  100. also returns the level the collection lives in the hierarchy.
  101. The user passes in a hiddev_collection_info struct with the index
  102. field set to the index that should be returned. The ioctl fills in
  103. the other fields. If the index is larger than the last collection
  104. index, the ioctl returns -1 and sets errno to -EINVAL.
  105. HIDIOCGDEVINFO
  106. - struct hiddev_devinfo (read)
  107. Gets a hiddev_devinfo structure which describes the device.
  108. HIDIOCGSTRING
  109. - struct hiddev_string_descriptor (read/write)
  110. Gets a string descriptor from the device. The caller must fill in the
  111. "index" field to indicate which descriptor should be returned.
  112. HIDIOCINITREPORT
  113. - (none)
  114. Instructs the kernel to retrieve all input and feature report values
  115. from the device. At this point, all the usage structures will contain
  116. current values for the device, and will maintain it as the device
  117. changes. Note that the use of this ioctl is unnecessary in general,
  118. since later kernels automatically initialize the reports from the
  119. device at attach time.
  120. HIDIOCGNAME
  121. - string (variable length)
  122. Gets the device name
  123. HIDIOCGREPORT
  124. - struct hiddev_report_info (write)
  125. Instructs the kernel to get a feature or input report from the device,
  126. in order to selectively update the usage structures (in contrast to
  127. INITREPORT).
  128. HIDIOCSREPORT
  129. - struct hiddev_report_info (write)
  130. Instructs the kernel to send a report to the device. This report can
  131. be filled in by the user through HIDIOCSUSAGE calls (below) to fill in
  132. individual usage values in the report before sending the report in full
  133. to the device.
  134. HIDIOCGREPORTINFO
  135. - struct hiddev_report_info (read/write)
  136. Fills in a hiddev_report_info structure for the user. The report is
  137. looked up by type (input, output or feature) and id, so these fields
  138. must be filled in by the user. The ID can be absolute -- the actual
  139. report id as reported by the device -- or relative --
  140. HID_REPORT_ID_FIRST for the first report, and (HID_REPORT_ID_NEXT |
  141. report_id) for the next report after report_id. Without a priori
  142. information about report ids, the right way to use this ioctl is to
  143. use the relative IDs above to enumerate the valid IDs. The ioctl
  144. returns non-zero when there is no more next ID. The real report ID is
  145. filled into the returned hiddev_report_info structure.
  146. HIDIOCGFIELDINFO
  147. - struct hiddev_field_info (read/write)
  148. Returns the field information associated with a report in a
  149. hiddev_field_info structure. The user must fill in report_id and
  150. report_type in this structure, as above. The field_index should also
  151. be filled in, which should be a number from 0 and maxfield-1, as
  152. returned from a previous HIDIOCGREPORTINFO call.
  153. HIDIOCGUCODE
  154. - struct hiddev_usage_ref (read/write)
  155. Returns the usage_code in a hiddev_usage_ref structure, given that
  156. its report type, report id, field index, and index within the
  157. field have already been filled into the structure.
  158. HIDIOCGUSAGE
  159. - struct hiddev_usage_ref (read/write)
  160. Returns the value of a usage in a hiddev_usage_ref structure. The
  161. usage to be retrieved can be specified as above, or the user can
  162. choose to fill in the report_type field and specify the report_id as
  163. HID_REPORT_ID_UNKNOWN. In this case, the hiddev_usage_ref will be
  164. filled in with the report and field information associated with this
  165. usage if it is found.
  166. HIDIOCSUSAGE
  167. - struct hiddev_usage_ref (write)
  168. Sets the value of a usage in an output report. The user fills in
  169. the hiddev_usage_ref structure as above, but additionally fills in
  170. the value field.
  171. HIDIOGCOLLECTIONINDEX
  172. - struct hiddev_usage_ref (write)
  173. Returns the collection index associated with this usage. This
  174. indicates where in the collection hierarchy this usage sits.
  175. HIDIOCGFLAG
  176. - int (read)
  177. HIDIOCSFLAG
  178. - int (write)
  179. These operations respectively inspect and replace the mode flags
  180. that influence the read() call above. The flags are as follows:
  181. HIDDEV_FLAG_UREF
  182. - read() calls will now return
  183. struct hiddev_usage_ref instead of struct hiddev_event.
  184. This is a larger structure, but in situations where the
  185. device has more than one usage in its reports with the
  186. same usage code, this mode serves to resolve such
  187. ambiguity.
  188. HIDDEV_FLAG_REPORT
  189. - This flag can only be used in conjunction
  190. with HIDDEV_FLAG_UREF. With this flag set, when the device
  191. sends a report, a struct hiddev_usage_ref will be returned
  192. to read() filled in with the report_type and report_id, but
  193. with field_index set to FIELD_INDEX_NONE. This serves as
  194. additional notification when the device has sent a report.