
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).