diff options
Diffstat (limited to 'Documentation/hid/hidraw.rst')
| -rw-r--r-- | Documentation/hid/hidraw.rst | 180 |
1 files changed, 180 insertions, 0 deletions
diff --git a/Documentation/hid/hidraw.rst b/Documentation/hid/hidraw.rst new file mode 100644 index 000000000..b717ee5cd --- /dev/null +++ b/Documentation/hid/hidraw.rst @@ -0,0 +1,180 @@ +================================================================ +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/ + https://web.archive.org/web/2019*/www.signal11.us + +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 uapi/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 returned report buffer will contain the +report number in the first byte, followed by the report data read from the +device. For devices which do not use numbered reports, the report data will +begin at the first byte of the returned buffer. + +HIDIOCSINPUT(len): + Send an Input Report + +This ioctl will send an input report to the device, using the control endpoint. +In most cases, setting an input HID report on a device is meaningless and has +no effect, but some devices may choose to use this to set or reset an initial +state of a report. The format of the buffer issued with this report is identical +to that of HIDIOCSFEATURE. + +HIDIOCGINPUT(len): + Get an Input Report + +This ioctl will request an input report from the device using the control +endpoint. This is slower on most devices where a dedicated In endpoint exists +for regular input reports, but allows the host to request the value of a +specific report number. Typically, this is used to request the initial states of +an input report of a device, before an application listens for normal reports via +the regular device read() interface. The format of the buffer issued with this report +is identical to that of HIDIOCGFEATURE. + +HIDIOCSOUTPUT(len): + Send an Output Report + +This ioctl will send an output report to the device, using the control endpoint. +This is slower on most devices where a dedicated Out endpoint exists for regular +output reports, but is added for completeness. Typically, this is used to set +the initial states of an output report of a device, before an application sends +updates via the regular device write() interface. The format of the buffer issued +with this report is identical to that of HIDIOCSFEATURE. + +HIDIOCGOUTPUT(len): + Get an Output Report + +This ioctl will request an output report from the device using the control +endpoint. Typically, this is used to retrive the initial state of +an output report of a device, before an application updates it as necessary either +via a HIDIOCSOUTPUT request, or the regular device write() interface. The format +of the buffer issued with this report is identical to that of HIDIOCGFEATURE. + +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 |