| HIDRAW - Raw Access to USB and Bluetooth Human Interface Devices | |
| ================================================================== | |
| The hidraw driver provides a raw interface to USB and Bluetooth Human | |
| Interface Devices (HIDs). It differs from hiddev in that reports sent and | |
| received are not parsed by the HID parser, but are sent to and received from | |
| the device unmodified. | |
| Hidraw should be used if the userspace application knows exactly how to | |
| communicate with the hardware device, and is able to construct the HID | |
| reports manually. This is often the case when making userspace drivers for | |
| custom HID devices. | |
| Hidraw is also useful for communicating with non-conformant HID devices | |
| which send and receive data in a way that is inconsistent with their report | |
| descriptors. Because hiddev parses reports which are sent and received | |
| through it, checking them against the device's report descriptor, such | |
| communication with these non-conformant devices is impossible using hiddev. | |
| Hidraw is the only alternative, short of writing a custom kernel driver, for | |
| these non-conformant devices. | |
| A benefit of hidraw is that its use by userspace applications is independent | |
| of the underlying hardware type. Currently, Hidraw is implemented for USB | |
| and Bluetooth. In the future, as new hardware bus types are developed which | |
| use the HID specification, hidraw will be expanded to add support for these | |
| new bus types. | |
| Hidraw uses a dynamic major number, meaning that udev should be relied on to | |
| create hidraw device nodes. Udev will typically create the device nodes | |
| directly under /dev (eg: /dev/hidraw0). As this location is distribution- | |
| and udev rule-dependent, applications should use libudev to locate hidraw | |
| devices attached to the system. There is a tutorial on libudev with a | |
| working example at: | |
| http://www.signal11.us/oss/udev/ | |
| The HIDRAW API | |
| --------------- | |
| read() | |
| ------- | |
| read() will read a queued report received from the HID device. On USB | |
| devices, the reports read using read() are the reports sent from the device | |
| on the INTERRUPT IN endpoint. By default, read() will block until there is | |
| a report available to be read. read() can be made non-blocking, by passing | |
| the O_NONBLOCK flag to open(), or by setting the O_NONBLOCK flag using | |
| fcntl(). | |
| On a device which uses numbered reports, the first byte of the returned data | |
| will be the report number; the report data follows, beginning in the second | |
| byte. For devices which do not use numbered reports, the report data | |
| will begin at the first byte. | |
| write() | |
| -------- | |
| The write() function will write a report to the device. For USB devices, if | |
| the device has an INTERRUPT OUT endpoint, the report will be sent on that | |
| endpoint. If it does not, the report will be sent over the control endpoint, | |
| using a SET_REPORT transfer. | |
| The first byte of the buffer passed to write() should be set to the report | |
| number. If the device does not use numbered reports, the first byte should | |
| be set to 0. The report data itself should begin at the second byte. | |
| ioctl() | |
| -------- | |
| Hidraw supports the following ioctls: | |
| HIDIOCGRDESCSIZE: Get Report Descriptor Size | |
| This ioctl will get the size of the device's report descriptor. | |
| HIDIOCGRDESC: Get Report Descriptor | |
| This ioctl returns the device's report descriptor using a | |
| hidraw_report_descriptor struct. Make sure to set the size field of the | |
| hidraw_report_descriptor struct to the size returned from HIDIOCGRDESCSIZE. | |
| HIDIOCGRAWINFO: Get Raw Info | |
| This ioctl will return a hidraw_devinfo struct containing the bus type, the | |
| vendor ID (VID), and product ID (PID) of the device. The bus type can be one | |
| of: | |
| BUS_USB | |
| BUS_HIL | |
| BUS_BLUETOOTH | |
| BUS_VIRTUAL | |
| which are defined in linux/input.h. | |
| HIDIOCGRAWNAME(len): Get Raw Name | |
| This ioctl returns a string containing the vendor and product strings of | |
| the device. The returned string is Unicode, UTF-8 encoded. | |
| HIDIOCGRAWPHYS(len): Get Physical Address | |
| This ioctl returns a string representing the physical address of the device. | |
| For USB devices, the string contains the physical path to the device (the | |
| USB controller, hubs, ports, etc). For Bluetooth devices, the string | |
| contains the hardware (MAC) address of the device. | |
| HIDIOCSFEATURE(len): Send a Feature Report | |
| This ioctl will send a feature report to the device. Per the HID | |
| specification, feature reports are always sent using the control endpoint. | |
| Set the first byte of the supplied buffer to the report number. For devices | |
| which do not use numbered reports, set the first byte to 0. The report data | |
| begins in the second byte. Make sure to set len accordingly, to one more | |
| than the length of the report (to account for the report number). | |
| HIDIOCGFEATURE(len): Get a Feature Report | |
| This ioctl will request a feature report from the device using the control | |
| endpoint. The first byte of the supplied buffer should be set to the report | |
| number of the requested report. For devices which do not use numbered | |
| reports, set the first byte to 0. The report will be returned starting at | |
| the first byte of the buffer (ie: the report number is not returned). | |
| Example | |
| --------- | |
| In samples/, find hid-example.c, which shows examples of read(), write(), | |
| and all the ioctls for hidraw. The code may be used by anyone for any | |
| purpose, and can serve as a starting point for developing applications using | |
| hidraw. | |
| Document by: | |
| Alan Ott <alan@signal11.us>, Signal 11 Software |