diff options
Diffstat (limited to 'linux/README.txt')
| -rw-r--r-- | linux/README.txt | 59 |
1 files changed, 59 insertions, 0 deletions
diff --git a/linux/README.txt b/linux/README.txt new file mode 100644 index 0000000..8006694 --- /dev/null +++ b/linux/README.txt @@ -0,0 +1,59 @@ + +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). |