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