Merge commit 'c41cb82ea7499c132546c1ab6f798deda6a9d7af' as 'hidapi'

1 files changed, 59 insertions, 0 deletions

diff --git a/hidapi/linux/README.txt b/hidapi/linux/README.txt
new file mode 100644
index 0000000..8006694
--- /dev/null
+++ b/hidapi/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).