hiddev.txt
上传用户:jlfgdled
上传日期:2013-04-10
资源大小:33168k
文件大小:6k
源码类别:

Linux/Unix编程

开发平台:

Unix_Linux

  1. Care and feeding of your Human Interface Devices
  2. INTRODUCTION
  3. In addition to the normal input type HID devices, USB also uses the
  4. human interface device protocols for things that are not really human
  5. interfaces, but have similar sorts of communication needs. The two big
  6. examples for this are power devices (especially uninterruptable power
  7. supplies) and monitor control on higher end monitors.
  8. To support these disparite requirements, the Linux USB system provides
  9. HID events to two seperate interfaces:
  10. * the input subsystem, which converts HID events into normal input
  11. device interfaces (such as keyboard, mouse and joystick) and a
  12. normalised event interface - see Documentation/input/input.txt
  13. * the hiddev interface, which provides fairly raw HID events
  14. The data flow for a HID event produced by a device is something like
  15. the following :
  16.  usb.c ---> hid.c  ----> input.c ----> [keyboard/mouse/joystick/event]
  17.                     |
  18.                     |
  19.                     --> hiddev.c ----> POWER / MONITOR CONTROL 
  20. In addition, other subsystems (apart from USB) can potentially feed
  21. events into the input subsystem, but these have no effect on the hid
  22. device interface.
  23. USING THE HID DEVICE INTERFACE
  24. The hiddev interface is a char interface using the normal USB major,
  25. with the minor numbers starting at 96 and finishing at 111. Therefore,
  26. you need the following commands:
  27. mknod /dev/usb/hiddev0 c 180 96
  28. mknod /dev/usb/hiddev1 c 180 97
  29. mknod /dev/usb/hiddev2 c 180 98
  30. mknod /dev/usb/hiddev3 c 180 99
  31. mknod /dev/usb/hiddev4 c 180 100
  32. mknod /dev/usb/hiddev5 c 180 101
  33. mknod /dev/usb/hiddev6 c 180 102
  34. mknod /dev/usb/hiddev7 c 180 103
  35. mknod /dev/usb/hiddev8 c 180 104
  36. mknod /dev/usb/hiddev9 c 180 105
  37. mknod /dev/usb/hiddev10 c 180 106
  38. mknod /dev/usb/hiddev11 c 180 107
  39. mknod /dev/usb/hiddev12 c 180 108
  40. mknod /dev/usb/hiddev13 c 180 109
  41. mknod /dev/usb/hiddev14 c 180 110
  42. mknod /dev/usb/hiddev15 c 180 111
  43. So you point your hiddev compliant user-space program at the correct
  44. interface for your device, and it all just works.
  45. Assuming that you have a hiddev compliant user-space program, of
  46. course. If you need to write one, read on.
  47. THE HIDDEV API
  48. This description should be read in conjunction with the HID
  49. specification, freely available from http://www.usb.org, and
  50. conveniently linked of http://www.linux-usb.org.
  51. The hiddev API uses a read() interface, and a set of ioctl() calls.
  52. read():
  53. This is the event interface. When the HID device performs an
  54. interrupt transfer, indicating a change of state, data will be made
  55. available at the associated hiddev device with the content of a struct
  56. hiddev_event: 
  57.        struct hiddev_event {
  58.            unsigned hid;
  59.            signed int value;
  60.        };
  61. containing the HID usage identifier for the status that changed, and
  62. the value that it was changed to. Note that the structure is defined
  63. within <linux/hiddev.h>, along with some other useful #defines and
  64. structures. 
  65. ioctl(): 
  66. This is the control interface. There are a number of controls: 
  67. HIDIOCGVERSION - int (read)
  68. Gets the version code out of the hiddev driver.
  69. HIDIOCAPPLICATION - (none)
  70. This ioctl call returns the HID application usage associated with the
  71. hid device. The third argument to ioctl() specifies which application
  72. index to get. This is useful when the device has more than one
  73. application collection. If the index is invalid (greater or equal to
  74. the number of application collections this device has) the ioctl
  75. returns -1. You can find out beforehand how many application
  76. collections the device has from the num_applications field from the
  77. hiddev_devinfo structure. 
  78. HIDIOCGDEVINFO - struct hiddev_devinfo (read)
  79. Gets a hiddev_devinfo structure which describes the device.
  80. HIDIOCGSTRING - struct struct hiddev_string_descriptor (read/write)
  81. Gets a string descriptor from the device. The caller must fill in the
  82. "index" field to indicate which descriptor should be returned.
  83. HIDIOCINITREPORT - (none)
  84. Instructs the kernel to retrieve all input and feature report values
  85. from the device. At this point, all the usage structures will contain
  86. current values for the device, and will maintain it as the device
  87. changes.
  88. HIDIOCGNAME - string (variable length)
  89. Gets the device name
  90. HIDIOCGREPORT - struct hiddev_report_info (write)
  91. Instructs the kernel to get a feature or input report from the device,
  92. in order to selectively update the usage structures (in contrast to
  93. INITREPORT). 
  94. HIDIOCSREPORT - struct hiddev_report_info (write)
  95. Instructs the kernel to send a report to the device. This report can
  96. be filled in by the user through HIDIOCSUSAGE calls (below) to fill in
  97. individual usage values in the report beforesending the report in full
  98. to the device. 
  99. HIDIOCGREPORTINFO - struct hiddev_report_info (read/write)
  100. Fills in a hiddev_report_info structure for the user. The report is
  101. looked up by type (input, output or feature) and id, so these fields
  102. must be filled in by the user. The ID can be absolute -- the actual
  103. report id as reported by the device -- or relative --
  104. HID_REPORT_ID_FIRST for the first report, and (HID_REPORT_ID_NEXT |
  105. report_id) for the next report after report_id. Without a-priori
  106. information about report ids, the right way to use this ioctl is to
  107. use the relative IDs above to enumerate the valid IDs. The ioctl
  108. returns non-zero when there is no more next ID. The real report ID is
  109. filled into the returned hiddev_report_info structure. 
  110. HIDIOCGFIELDINFO - struct hiddev_field_info (read/write)
  111. Returns the field information associated with a report in a
  112. hiddev_field_info structure. The user must fill in report_id and
  113. report_type in this structure, as above. The field_index should also
  114. be filled in, which should be a number from 0 and maxfield-1, as
  115. returned from a previous HIDIOCGREPORTINFO call. 
  116. HIDIOCGUCODE - struct hiddev_usage_ref (read/write)
  117. Returns the usage_code in a hiddev_usage_ref structure, given that
  118. given its report type, report id, field index, and index within the
  119. field have already been filled into the structure.
  120. HIDIOCGUSAGE - struct hiddev_usage_ref (read/write)
  121. Returns the value of a usage in a hiddev_usage_ref structure. The
  122. usage to be retrieved can be specified as above, or the user can
  123. choose to fill in the report_type field and specify the report_id as
  124. HID_REPORT_ID_UNKNOWN. In this case, the hiddev_usage_ref will be
  125. filled in with the report and field infomation associated with this
  126. usage if it is found. 
  127. HIDIOCSUSAGE - struct hiddev_usage_ref (write)
  128. Sets the value of a usage in an output report.