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 returned report buffer will contain the 127report number in the first byte, followed by the report data read from the 128device. For devices which do not use numbered reports, the report data will 129begin at the first byte of the returned buffer. 130 131HIDIOCSINPUT(len): 132 Send an Input Report 133 134This ioctl will send an input report to the device, using the control endpoint. 135In most cases, setting an input HID report on a device is meaningless and has 136no effect, but some devices may choose to use this to set or reset an initial 137state of a report. The format of the buffer issued with this report is identical 138to that of HIDIOCSFEATURE. 139 140HIDIOCGINPUT(len): 141 Get an Input Report 142 143This ioctl will request an input report from the device using the control 144endpoint. This is slower on most devices where a dedicated In endpoint exists 145for regular input reports, but allows the host to request the value of a 146specific report number. Typically, this is used to request the initial states of 147an input report of a device, before an application listens for normal reports via 148the regular device read() interface. The format of the buffer issued with this report 149is identical to that of HIDIOCGFEATURE. 150 151HIDIOCSOUTPUT(len): 152 Send an Output Report 153 154This ioctl will send an output report to the device, using the control endpoint. 155This is slower on most devices where a dedicated Out endpoint exists for regular 156output reports, but is added for completeness. Typically, this is used to set 157the initial states of an output report of a device, before an application sends 158updates via the regular device write() interface. The format of the buffer issued 159with this report is identical to that of HIDIOCSFEATURE. 160 161HIDIOCGOUTPUT(len): 162 Get an Output Report 163 164This ioctl will request an output report from the device using the control 165endpoint. Typically, this is used to retrive the initial state of 166an output report of a device, before an application updates it as necessary either 167via a HIDIOCSOUTPUT request, or the regular device write() interface. The format 168of the buffer issued with this report is identical to that of HIDIOCGFEATURE. 169 170Example 171------- 172In samples/, find hid-example.c, which shows examples of read(), write(), 173and all the ioctls for hidraw. The code may be used by anyone for any 174purpose, and can serve as a starting point for developing applications using 175hidraw. 176 177Document by: 178 179 Alan Ott <alan@signal11.us>, Signal 11 Software 180