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
38The HIDRAW API
39---------------
40
41read()
42-------
43read() will read a queued report received from the HID device. On USB
44devices, the reports read using read() are the reports sent from the device
45on the INTERRUPT IN endpoint.  By default, read() will block until there is
46a report available to be read.  read() can be made non-blocking, by passing
47the O_NONBLOCK flag to open(), or by setting the O_NONBLOCK flag using
48fcntl().
49
50On a device which uses numbered reports, the first byte of the returned data
51will be the report number; the report data follows, beginning in the second
52byte.  For devices which do not use numbered reports, the report data
53will begin at the first byte.
54
55write()
56-------
57The write() function will write a report to the device. For USB devices, if
58the device has an INTERRUPT OUT endpoint, the report will be sent on that
59endpoint. If it does not, the report will be sent over the control endpoint,
60using a SET_REPORT transfer.
61
62The first byte of the buffer passed to write() should be set to the report
63number.  If the device does not use numbered reports, the first byte should
64be set to 0. The report data itself should begin at the second byte.
65
66ioctl()
67-------
68Hidraw supports the following ioctls:
69
70HIDIOCGRDESCSIZE:
71	Get Report Descriptor Size
72
73This ioctl will get the size of the device's report descriptor.
74
75HIDIOCGRDESC:
76	Get Report Descriptor
77
78This ioctl returns the device's report descriptor using a
79hidraw_report_descriptor struct.  Make sure to set the size field of the
80hidraw_report_descriptor struct to the size returned from HIDIOCGRDESCSIZE.
81
82HIDIOCGRAWINFO:
83	Get Raw Info
84
85This ioctl will return a hidraw_devinfo struct containing the bus type, the
86vendor ID (VID), and product ID (PID) of the device. The bus type can be one
87of::
88
89	- BUS_USB
90	- BUS_HIL
91	- BUS_BLUETOOTH
92	- BUS_VIRTUAL
93
94which are defined in uapi/linux/input.h.
95
96HIDIOCGRAWNAME(len):
97	Get Raw Name
98
99This ioctl returns a string containing the vendor and product strings of
100the device.  The returned string is Unicode, UTF-8 encoded.
101
102HIDIOCGRAWPHYS(len):
103	Get Physical Address
104
105This ioctl returns a string representing the physical address of the device.
106For USB devices, the string contains the physical path to the device (the
107USB controller, hubs, ports, etc).  For Bluetooth devices, the string
108contains the hardware (MAC) address of the device.
109
110HIDIOCSFEATURE(len):
111	Send a Feature Report
112
113This ioctl will send a feature report to the device.  Per the HID
114specification, feature reports are always sent using the control endpoint.
115Set the first byte of the supplied buffer to the report number.  For devices
116which do not use numbered reports, set the first byte to 0. The report data
117begins in the second byte. Make sure to set len accordingly, to one more
118than the length of the report (to account for the report number).
119
120HIDIOCGFEATURE(len):
121	Get a Feature Report
122
123This ioctl will request a feature report from the device using the control
124endpoint.  The first byte of the supplied buffer should be set to the report
125number of the requested report.  For devices which do not use numbered
126reports, set the first byte to 0.  The report will be returned starting at
127the first byte of the buffer (ie: the report number is not returned).
128
129Example
130-------
131In samples/, find hid-example.c, which shows examples of read(), write(),
132and all the ioctls for hidraw.  The code may be used by anyone for any
133purpose, and can serve as a starting point for developing applications using
134hidraw.
135
136Document by:
137
138	Alan Ott <alan@signal11.us>, Signal 11 Software
139