Documentation/hid/hidraw.rst

   1 ================================================================
   2 HIDRAW - Raw Access to USB and Bluetooth Human Interface Devices
   3 ================================================================
   4
   5 The hidraw driver provides a raw interface to USB and Bluetooth Human
   6 Interface Devices (HIDs).  It differs from hiddev in that reports sent and
   7 received are not parsed by the HID parser, but are sent to and received from
   8 the device unmodified.
   9
  10 Hidraw should be used if the userspace application knows exactly how to
  11 communicate with the hardware device, and is able to construct the HID
  12 reports manually.  This is often the case when making userspace drivers for
  13 custom HID devices.
  14
  15 Hidraw is also useful for communicating with non-conformant HID devices
  16 which send and receive data in a way that is inconsistent with their report
  17 descriptors.  Because hiddev parses reports which are sent and received
  18 through it, checking them against the device's report descriptor, such
  19 communication with these non-conformant devices is impossible using hiddev.
  20 Hidraw is the only alternative, short of writing a custom kernel driver, for
  21 these non-conformant devices.
  22
  23 A benefit of hidraw is that its use by userspace applications is independent
  24 of the underlying hardware type.  Currently, Hidraw is implemented for USB
  25 and Bluetooth.  In the future, as new hardware bus types are developed which
  26 use the HID specification, hidraw will be expanded to add support for these
  27 new bus types.
  28
  29 Hidraw uses a dynamic major number, meaning that udev should be relied on to
  30 create hidraw device nodes.  Udev will typically create the device nodes
  31 directly under /dev (eg: /dev/hidraw0).  As this location is distribution-
  32 and udev rule-dependent, applications should use libudev to locate hidraw
  33 devices attached to the system.  There is a tutorial on libudev with a
  34 working example at:
  35
  36         http://www.signal11.us/oss/udev/
  37
  38 The HIDRAW API
  39 ---------------
  40
  41 read()
  42 -------
  43 read() will read a queued report received from the HID device. On USB
  44 devices, the reports read using read() are the reports sent from the device
  45 on the INTERRUPT IN endpoint.  By default, read() will block until there is
  46 a report available to be read.  read() can be made non-blocking, by passing
  47 the O_NONBLOCK flag to open(), or by setting the O_NONBLOCK flag using
  48 fcntl().
  49
  50 On a device which uses numbered reports, the first byte of the returned data
  51 will be the report number; the report data follows, beginning in the second
  52 byte.  For devices which do not use numbered reports, the report data
  53 will begin at the first byte.
  54
  55 write()
  56 -------
  57 The write() function will write a report to the device. For USB devices, if
  58 the device has an INTERRUPT OUT endpoint, the report will be sent on that
  59 endpoint. If it does not, the report will be sent over the control endpoint,
  60 using a SET_REPORT transfer.
  61
  62 The first byte of the buffer passed to write() should be set to the report
  63 number.  If the device does not use numbered reports, the first byte should
  64 be set to 0. The report data itself should begin at the second byte.
  65
  66 ioctl()
  67 -------
  68 Hidraw supports the following ioctls:
  69
  70 HIDIOCGRDESCSIZE:
  71         Get Report Descriptor Size
  72
  73 This ioctl will get the size of the device's report descriptor.
  74
  75 HIDIOCGRDESC:
  76         Get Report Descriptor
  77
  78 This ioctl returns the device's report descriptor using a
  79 hidraw_report_descriptor struct.  Make sure to set the size field of the
  80 hidraw_report_descriptor struct to the size returned from HIDIOCGRDESCSIZE.
  81
  82 HIDIOCGRAWINFO:
  83         Get Raw Info
  84
  85 This ioctl will return a hidraw_devinfo struct containing the bus type, the
  86 vendor ID (VID), and product ID (PID) of the device. The bus type can be one
  87 of::
  88
  89         - BUS_USB
  90         - BUS_HIL
  91         - BUS_BLUETOOTH
  92         - BUS_VIRTUAL
  93
  94 which are defined in uapi/linux/input.h.
  95
  96 HIDIOCGRAWNAME(len):
  97         Get Raw Name
  98
  99 This ioctl returns a string containing the vendor and product strings of
 100 the device.  The returned string is Unicode, UTF-8 encoded.
 101
 102 HIDIOCGRAWPHYS(len):
 103         Get Physical Address
 104
 105 This ioctl returns a string representing the physical address of the device.
 106 For USB devices, the string contains the physical path to the device (the
 107 USB controller, hubs, ports, etc).  For Bluetooth devices, the string
 108 contains the hardware (MAC) address of the device.
 109
 110 HIDIOCSFEATURE(len):
 111         Send a Feature Report
 112
 113 This ioctl will send a feature report to the device.  Per the HID
 114 specification, feature reports are always sent using the control endpoint.
 115 Set the first byte of the supplied buffer to the report number.  For devices
 116 which do not use numbered reports, set the first byte to 0. The report data
 117 begins in the second byte. Make sure to set len accordingly, to one more
 118 than the length of the report (to account for the report number).
 119
 120 HIDIOCGFEATURE(len):
 121         Get a Feature Report
 122
 123 This ioctl will request a feature report from the device using the control
 124 endpoint.  The first byte of the supplied buffer should be set to the report
 125 number of the requested report.  For devices which do not use numbered
 126 reports, set the first byte to 0.  The returned report buffer will contain the
 127 report number in the first byte, followed by the report data read from the
 128 device.  For devices which do not use numbered reports, the report data will
 129 begin at the first byte of the returned buffer.
 130
 131 HIDIOCSINPUT(len):
 132         Send an Input Report
 133
 134 This ioctl will send an input report to the device, using the control endpoint.
 135 In most cases, setting an input HID report on a device is meaningless and has
 136 no effect, but some devices may choose to use this to set or reset an initial
 137 state of a report.  The format of the buffer issued with this report is identical
 138 to that of HIDIOCSFEATURE.
 139
 140 HIDIOCGINPUT(len):
 141         Get an Input Report
 142
 143 This ioctl will request an input report from the device using the control
 144 endpoint.  This is slower on most devices where a dedicated In endpoint exists
 145 for regular input reports, but allows the host to request the value of a
 146 specific report number.  Typically, this is used to request the initial states of
 147 an input report of a device, before an application listens for normal reports via
 148 the regular device read() interface.  The format of the buffer issued with this report
 149 is identical to that of HIDIOCGFEATURE.
 150
 151 HIDIOCSOUTPUT(len):
 152         Send an Output Report
 153
 154 This ioctl will send an output report to the device, using the control endpoint.
 155 This is slower on most devices where a dedicated Out endpoint exists for regular
 156 output reports, but is added for completeness.  Typically, this is used to set
 157 the initial states of an output report of a device, before an application sends
 158 updates via the regular device write() interface. The format of the buffer issued
 159 with this report is identical to that of HIDIOCSFEATURE.
 160
 161 HIDIOCGOUTPUT(len):
 162         Get an Output Report
 163
 164 This ioctl will request an output report from the device using the control
 165 endpoint.  Typically, this is used to retrive the initial state of
 166 an output report of a device, before an application updates it as necessary either
 167 via a HIDIOCSOUTPUT request, or the regular device write() interface.  The format
 168 of the buffer issued with this report is identical to that of HIDIOCGFEATURE.
 169
 170 Example
 171 -------
 172 In samples/, find hid-example.c, which shows examples of read(), write(),
 173 and all the ioctls for hidraw.  The code may be used by anyone for any
 174 purpose, and can serve as a starting point for developing applications using
 175 hidraw.
 176
 177 Document by:
 178
 179         Alan Ott <alan@signal11.us>, Signal 11 Software