HIDRAW - Raw Access to USB and Bluetooth Human Interface Devices

The hidraw driver provides a raw interface to USB and Bluetooth HumanInterface Devices (HIDs). It differs from hiddev in that reports sent andreceived are not parsed by the HID parser, but are sent to and received fromthe device unmodified.

Hidraw should be used if the userspace application knows exactly how tocommunicate with the hardware device, and is able to construct the HIDreports manually. This is often the case when making userspace drivers forcustom HID devices.

Hidraw is also useful for communicating with non-conformant HID deviceswhich send and receive data in a way that is inconsistent with their reportdescriptors. Because hiddev parses reports which are sent and receivedthrough it, checking them against the device’s report descriptor, suchcommunication with these non-conformant devices is impossible using hiddev.Hidraw is the only alternative, short of writing a custom kernel driver, forthese non-conformant devices.

A benefit of hidraw is that its use by userspace applications is independentof the underlying hardware type. Currently, hidraw is implemented for USBand Bluetooth. In the future, as new hardware bus types are developed whichuse the HID specification, hidraw will be expanded to add support for thesenew bus types.

Hidraw uses a dynamic major number, meaning that udev should be relied on tocreate hidraw device nodes. Udev will typically create the device nodesdirectly under /dev (eg: /dev/hidraw0). As this location is distribution-and udev rule-dependent, applications should use libudev to locate hidrawdevices attached to the system. There is a tutorial on libudev with aworking 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 USBdevices, the reports read using read() are the reports sent from the deviceon the INTERRUPT IN endpoint. By default, read() will block until there isa report available to be read. read() can be made non-blocking, by passingthe O_NONBLOCK flag to open(), or by setting the O_NONBLOCK flag usingfcntl().

On a device which uses numbered reports, the first byte of the returned datawill be the report number; the report data follows, beginning in the secondbyte. For devices which do not use numbered reports, the report datawill begin at the first byte.

write()

The write() function will write a report to the device. For USB devices, ifthe device has an INTERRUPT OUT endpoint, the report will be sent on thatendpoint. 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 reportnumber. If the device does not use numbered reports, the first byte shouldbe 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 ahidraw_report_descriptor struct. Make sure to set the size field of thehidraw_report_descriptorstructto the size returned from HIDIOCGRDESCSIZE.

HIDIOCGRAWINFO:

Get Raw Info

This ioctl will return a hidraw_devinfostructcontaining the bus type, thevendor ID (VID), and product ID (PID) of the device. The bus type can be oneof:

- 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 ofthe 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 (theUSB controller, hubs, ports, etc). For Bluetooth devices, the stringcontains 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 HIDspecification, feature reports are always sent using the control endpoint.Set the first byte of the supplied buffer to the report number. For deviceswhich do not use numbered reports, set the first byte to 0. The report databegins in the second byte. Make sure to set len accordingly, to one morethan 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 controlendpoint. The first byte of the supplied buffer should be set to the reportnumber of the requested report. For devices which do not use numberedreports, set the first byte to 0. The returned report buffer will contain thereport number in the first byte, followed by the report data read from thedevice. For devices which do not use numbered reports, the report data willbegin 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 hasno effect, but some devices may choose to use this to set or reset an initialstate of a report. The format of the buffer issued with this report is identicalto that of HIDIOCSFEATURE.

HIDIOCGINPUT(len):

Get an Input Report

This ioctl will request an input report from the device using the controlendpoint. This is slower on most devices where a dedicated In endpoint existsfor regular input reports, but allows the host to request the value of aspecific report number. Typically, this is used to request the initial states ofan input report of a device, before an application listens for normal reports viathe regular device read() interface. The format of the buffer issued with this reportis 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 regularoutput reports, but is added for completeness. Typically, this is used to setthe initial states of an output report of a device, before an application sendsupdates via the regular device write() interface. The format of the buffer issuedwith 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 controlendpoint. Typically, this is used to retrieve the initial state ofan output report of a device, before an application updates it as necessary eithervia a HIDIOCSOUTPUT request, or the regular device write() interface. The formatof 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 anypurpose, and can serve as a starting point for developing applications usinghidraw.

Document by:

Alan Ott <alan@signal11.us>, Signal 11 Software