|
|
There are two implementations of HIDAPI for Linux. One (hid.c) uses the
Linux hidraw driver, and the other (hid-libusb.c) uses libusb. Which one you
use depends on your application. Complete functionality of the hidraw
version depends on patches to the Linux kernel which are not currently in
the mainline. These patches have to do with sending and receiving feature
reports. The libusb implementation uses libusb to talk directly to the
device, bypassing any Linux HID driver. The disadvantage of the libusb
version is that it will only work with USB devices, while the hidraw
implementation will work with Bluetooth devices as well.
To use HIDAPI, simply drop either hid.c or hid-libusb.c into your
application and build using the build parameters in the Makefile.
By default, on Linux, the Makefile in this directory is configured to use
the libusb implementation. To switch to the hidraw implementation, simply
change hid-libusb.c to hid.c in the Makefile.
Libusb Implementation notes
----------------------------
For the libusb implementation, libusb-1.0 must be installed. Libusb 1.0 is
different than the legacy libusb 0.1 which is installed on many systems. To
install libusb-1.0 on Ubuntu and other Debian-based systems, run:
sudo apt-get install libusb-1.0-0-dev
Hidraw Implementation notes
----------------------------
For the hidraw implementation, libudev headers and libraries are required to
build hidapi programs. To install libudev libraries on Ubuntu,
and other Debian-based systems, run:
sudo apt-get install libudev-dev
On Redhat-based systems, run the following as root:
yum install libudev-devel
Unfortunately, the hidraw driver, which the linux version of hidapi is based
on, contains bugs in kernel versions < 2.6.36, which the client application
should be aware of.
Bugs (hidraw implementation only):
-----------------------------------
On Kernel versions < 2.6.34, if your device uses numbered reports, an extra
byte will be returned at the beginning of all reports returned from read()
for hidraw devices. This is worked around in the libary. No action should be
necessary in the client library.
On Kernel versions < 2.6.35, reports will only be sent using a Set_Report
transfer on the CONTROL endpoint. No data will ever be sent on an Interrupt
Out endpoint if one exists. This is fixed in 2.6.35. In 2.6.35, OUTPUT
reports will be sent to the device on the first INTERRUPT OUT endpoint if it
exists; If it does not exist, OUTPUT reports will be sent on the CONTROL
endpoint.
On Kernel versions < 2.6.36, add an extra byte containing the report number
to sent reports if numbered reports are used, and the device does not
contain an INTERRPUT OUT endpoint for OUTPUT transfers. For example, if
your device uses numbered reports and wants to send {0x2 0xff 0xff 0xff} to
the device (0x2 is the report number), you must send {0x2 0x2 0xff 0xff
0xff}. If your device has the optional Interrupt OUT endpoint, this does not
apply (but really on 2.6.35 only, because 2.6.34 won't use the interrupt
out endpoint).
|
By viewing downloads associated with this article you agree to the Terms of Service and the article's licence.
If a file you wish to view isn't highlighted, and is a text file (not binary), please
let us know and we'll add colourisation support for it.
David Moloney holds a B.Eng. degree from Dublin City University, and Ph.D. in Engineering from Trinity College Dublin. For the past 25 years he has worked in microelectronics starting in 1985 with Infineon in Munich and ST Microelectronics in Milan, before returning to Ireland 1994 to help found a series of start-up technology companies including Parthus-CEVA and Silansys. David is currently co-founder (2005) and CTO of Movidius Ltd., a fabless semiconductor company headquartered in Dublin and focused on the design of software programmable multimedia accelerator SoCs. He holds 18 US patents and numerous conference and journal papers on DSP and computer architecture. David is a member of the IEEE.
Submit an article or tip