README.txt (2869B)
1 2 There are two implementations of HIDAPI for Linux. One (linux/hid.c) uses the 3 Linux hidraw driver, and the other (libusb/hid.c) uses libusb. Which one you 4 use depends on your application. Complete functionality of the hidraw 5 version depends on patches to the Linux kernel which are not currently in 6 the mainline. These patches have to do with sending and receiving feature 7 reports. The libusb implementation uses libusb to talk directly to the 8 device, bypassing any Linux HID driver. The disadvantage of the libusb 9 version is that it will only work with USB devices, while the hidraw 10 implementation will work with Bluetooth devices as well. 11 12 To use HIDAPI, simply drop either linux/hid.c or libusb/hid.c into your 13 application and build using the build parameters in the Makefile. 14 15 16 Libusb Implementation notes 17 ---------------------------- 18 For the libusb implementation, libusb-1.0 must be installed. Libusb 1.0 is 19 different than the legacy libusb 0.1 which is installed on many systems. To 20 install libusb-1.0 on Ubuntu and other Debian-based systems, run: 21 sudo apt-get install libusb-1.0-0-dev 22 23 24 Hidraw Implementation notes 25 ---------------------------- 26 For the hidraw implementation, libudev headers and libraries are required to 27 build hidapi programs. To install libudev libraries on Ubuntu, 28 and other Debian-based systems, run: 29 sudo apt-get install libudev-dev 30 31 On Redhat-based systems, run the following as root: 32 yum install libudev-devel 33 34 Unfortunately, the hidraw driver, which the linux version of hidapi is based 35 on, contains bugs in kernel versions < 2.6.36, which the client application 36 should be aware of. 37 38 Bugs (hidraw implementation only): 39 ----------------------------------- 40 On Kernel versions < 2.6.34, if your device uses numbered reports, an extra 41 byte will be returned at the beginning of all reports returned from read() 42 for hidraw devices. This is worked around in the libary. No action should be 43 necessary in the client library. 44 45 On Kernel versions < 2.6.35, reports will only be sent using a Set_Report 46 transfer on the CONTROL endpoint. No data will ever be sent on an Interrupt 47 Out endpoint if one exists. This is fixed in 2.6.35. In 2.6.35, OUTPUT 48 reports will be sent to the device on the first INTERRUPT OUT endpoint if it 49 exists; If it does not exist, OUTPUT reports will be sent on the CONTROL 50 endpoint. 51 52 On Kernel versions < 2.6.36, add an extra byte containing the report number 53 to sent reports if numbered reports are used, and the device does not 54 contain an INTERRPUT OUT endpoint for OUTPUT transfers. For example, if 55 your device uses numbered reports and wants to send {0x2 0xff 0xff 0xff} to 56 the device (0x2 is the report number), you must send {0x2 0x2 0xff 0xff 57 0xff}. If your device has the optional Interrupt OUT endpoint, this does not 58 apply (but really on 2.6.35 only, because 2.6.34 won't use the interrupt 59 out endpoint).