Mess with the open flags hoping that two things can be achieved:
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()
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
This is necessary for cross-compile on Linux. While WinIoCTL.h is the
actual name of the file on Windows, it is apparently not the case on
the Linux cross-compile tools.
This patch is from Ryan Pavlik <abiryan@ryand.net>
Changed to use libusb_handle_events() instead of
libusb_handle_events_timeout() on the read thread. This increases
performance because the read thread now doesn't get woken up for no
reason.
Also, when the read thread exits, signal any waiting threads (which are
waiting in hid_read_timeout() so that they don't block forever if another
thread calls hid_close() or if the device becomes disconnected.
This was all kicked off by some suggestions by Hans Hübner
<hans.huebner@gmail.com>
Multiple users have reported the need to pass
SHARE_MODE_READ|SHARE_MODE_WRITE to CreateFileA(). It seems that some
devices will not open at all if sharing is not requested. This commit
makes it so that CreateFileA() will be tried twice, the first time with
sharing mode OFF (passing 0x0 to the ShareMode parameter of CreateFileA()),
and if that fails, it will try to open the device with share mode ON
(passing the above SHARE_MODE_ flags to the ShareMode parameter of
CreateFileA()). This will have the following effects:
For normal devices:
Devices will open as normal. Only one instance can be opened at a time.
For devices which require share mode to be on:
Devices will now open (they would not open at all before). Multiple
instances can be opened. This is less than desirable, but the
alternative is that these devices don't open at all.
Although the Windows API doesn't provide direct access to interface number,
on child devices representing the interfaces of a composite device, it is
parsable from the device path. An excerpt of a path for interface 1 of a
Razer Hydra device is as follows:
\?\hid#vid_1532&pid_0300&mi_01
See table 4 and related text here:
http://msdn.microsoft.com/en-us/windows/hardware/gg487473
This patch, if a path is available, and further, if &mi_ is found, parses
what it can for a hex value into the interface_number field. If there is
any problem, the invalid value (-1) is used instead.
Patch from Ryan Pavlik <abiryan@ryand.net> with modifications by Alan Ott.
Alan Ott