Addresses an issue with the return type of HidP_GetCaps() which was
returning the wrong status code because of the invalid return type of
BOOLEAN which is a UCHAR. The return code is supposed to be 0x110000
which obviously doesn't fit in a UCHAR so it was being rounded to
0x0. Basically, no return codes were ever making it through that call.
There are type definitions that allow compilation without requiring the
Windows DDK to be installed for compilation/linking however one of the
types used was wrong and when actually compiled against the DDK, it
would fail.
This adds a FreeBSD implementation to HIDAPI using the libusb back-end. The
libusb/ folder now contains the libusb implementation and associated
Makefiles for Linux and FreeBSD. All libusb code has been removed from the
linux/ folder, so that the code in libusb/ can be shared by both (and
future) platforms.
This commit renames linux/hid-libusb.c to libusb/hid.c. Make sure to
use git log --follow to see full history of that file.
This code was written by:
Alex Dupre <ale@FreeBSD.org>
Alan Ott <alan@signal11.us>
This happens if a device gets opened a second time. The call to
libusb_submit_transfer() will fail, indicating that the read thread should
be shut down.
get_serial_number()
get_manufacturer_string()
get_product_string()
This is to match the documentation in the header file, returning 0 on
success and -1 on error.
get_serial_number()
get_manufacturer_string()
get_product_string()
This matches the documentation in header file to return 0 on success and -1
on error.
Change the CreateFileA() flags to support the following:
1. Devices can still be opened in exclusive mode,
2. Devices which must be opened in shared mode can still be opened.
3. Opened devices (even with exclusive opens) still show in
hid_enumerate()
Thanks to github user vanweric for suggesting these flags and to Brendan
Shanks for discussion and testing.
Use a private libusb_context to avoid conflicts between
multiple libusb instances inside a single application
process. Many 3rd party libraries use libusb as backend,
so there is a good chance of collisions if the default NULL
context is used.
Modified by Alan Ott to also remove the initialized
variable since it's no longer needed (since we can use
the context instead), to make the style consistent, and
to remove unnecessary checks for initialized before calling
hid_init().
Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Alan Ott <alan@signal11.us>
Fix the problem where hid_enumerate() will crash if any of the HID devices
attached to the system are opened in exclusive mode (using
kIOHIDOptionsTypeSeizeDevice from IOHIDManagerOpen()). According to reports,
some Logitech devices have software which opens devices in exclusive mode,
causing HIDAPI-based programs to crash on systems where these Logitech
devices (and their accompanying software) are installed.
The fix is simple enough. IOHIDManagerOpen() does not need to be called from
HIDAPI, contrary to the examples in Apple's Technical Note TN2187. From
examining the IOHIDManager source[1], it appears that "opening" the
IOHIDManager (not the IOHIDDevice) causes IOHIDManager to try to open all
matching devices connected to the system, failing if even one device cannot
be opened. (Calling IOHIDManagerOpen() does indeed call IOHIDDeviceOpen()
for every matching connected device and for every future matching connected
device as well). HIDAPI of course tries to match all devices (by passing
NULL to IOHIDManagerSetDeviceMatching()), hence the issue.
Empirical evidence first suggested that IOHIDManagerOpen() did not actually
need to be called, and examination of the source[1] seems to confirm that it
only gets in the way.
Many thanks to Brendan Shanks, Bill Good, Github user darthrake, and Vitali
Lovich for pointing this out and participating in the information gathering,
debugging, and discussion.
[1] http://opensource.apple.com/source/IOKitUser/IOKitUser-502/hid.subproj/IOHIDManager.c
Signed-off-by: Alan Ott <alan@signal11.us>
Surrounding application may not be using a run loop (or may not have
given it a chance to run). Process any outstanding events (this does
imply that hid_enumerate will take about at least 1ms to process).
On Windows, data shorter than the output report length must be padded.
This is because in the case of multiple reports, Windows expects the number
of bytes which are in the _longest_ report to be given to WriteFile() even
if the user is sending a report which has fewer bytes.
This allocates a temporary buffer in the case that the user passes in too
few bytes.
From: Vitali Lovich <vlovich@gmail.com>
Modified-by: Alan Ott <alan@signal11.us>
The previous mac/hid.c implementation was kind of problematic. It worked
fine on 10.5, but on 10.7 I have gotten reports of really weird stuff
happening, such as the report callback being called with invalid context
data.
The problem was, the callback's don't get removed from the callback list
when you call IOHIDDeviceClose() in 10.7 like they used to. This means that
the report callback must be unregistered at hid_close() time. Further the
unregister will not work unless you pass _exactly_ the same parameters into
IOHIDDeviceRegisterInputReportCallback() that were passed in the first time
(with the exception of the function being NULL). Thanks Apple for your
stellar documentation and commitment to backwards compatibility.
Further, with the previous implementation, the OS only seemed to buffer
up 4 reports in between calls to CFRunLoopRun*(), causing the potential
for reports to get lost. The new method, being on a separate thread,
will now buffer up to a configurable 30 reports.
Carbon is no good on 10.5 and later on 64-bit. Github user
dportabella found a workaround in Cocoa[1], and I added code
to make it handle the events from the dock, like the carbon
version did.
[1] https://github.com/signal11/hidapi/issues/14
