Blame | Last modification | View Log | Download
There are two implementations of HIDAPI for Linux. One (hid.c) uses theLinux hidraw driver, and the other (hid-libusb.c) uses libusb. Which one youuse depends on your application. Complete functionality of the hidrawversion depends on patches to the Linux kernel which are not currently inthe mainline. These patches have to do with sending and receiving featurereports. The libusb implementation uses libusb to talk directly to thedevice, bypassing any Linux HID driver. The disadvantage of the libusbversion is that it will only work with USB devices, while the hidrawimplementation will work with Bluetooth devices as well.To use HIDAPI, simply drop either hid.c or hid-libusb.c into yourapplication and build using the build parameters in the Makefile.By default, on Linux, the Makefile in this directory is configured to usethe libusb implementation. To switch to the hidraw implementation, simplychange 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 isdifferent than the legacy libusb 0.1 which is installed on many systems. Toinstall libusb-1.0 on Ubuntu and other Debian-based systems, run:sudo apt-get install libusb-1.0-0-devHidraw Implementation notes----------------------------For the hidraw implementation, libudev headers and libraries are required tobuild hidapi programs. To install libudev libraries on Ubuntu,and other Debian-based systems, run:sudo apt-get install libudev-devOn Redhat-based systems, run the following as root:yum install libudev-develUnfortunately, the hidraw driver, which the linux version of hidapi is basedon, contains bugs in kernel versions < 2.6.36, which the client applicationshould be aware of.Bugs (hidraw implementation only):-----------------------------------On Kernel versions < 2.6.34, if your device uses numbered reports, an extrabyte 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 benecessary in the client library.On Kernel versions < 2.6.35, reports will only be sent using a Set_Reporttransfer on the CONTROL endpoint. No data will ever be sent on an InterruptOut endpoint if one exists. This is fixed in 2.6.35. In 2.6.35, OUTPUTreports will be sent to the device on the first INTERRUPT OUT endpoint if itexists; If it does not exist, OUTPUT reports will be sent on the CONTROLendpoint.On Kernel versions < 2.6.36, add an extra byte containing the report numberto sent reports if numbered reports are used, and the device does notcontain an INTERRPUT OUT endpoint for OUTPUT transfers. For example, ifyour device uses numbered reports and wants to send {0x2 0xff 0xff 0xff} tothe device (0x2 is the report number), you must send {0x2 0x2 0xff 0xff0xff}. If your device has the optional Interrupt OUT endpoint, this does notapply (but really on 2.6.35 only, because 2.6.34 won't use the interruptout endpoint).