You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
119 lines
5.3 KiB
119 lines
5.3 KiB
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
|
|
|