60 lines
2.8 KiB
Plaintext
60 lines
2.8 KiB
Plaintext
|
|
||
|
|
There are two implementations of HIDAPI for Linux. One (linux/hid.c) uses the
|
||
|
|
Linux hidraw driver, and the other (libusb/hid.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 linux/hid.c or libusb/hid.c into your
|
||
|
|
application and build using the build parameters 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).
|