Older versions of MSVC (for example when using Visual Studio 10) don't
yet support variable declaration in the middle of blocks:
hidapi\windows\hid.c(845) : error C2275: 'BOOL' : illegal use of this type as an expression
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\windef.h(153) : see declaration of 'BOOL'
Move the declaration of res to the beginning of the function. Like in
hid_get_feature_report, only res is moved, essentially ignoring the #if
0 block (or assuming it will never be enabled).
This allows to build the test program with toolchains that don't have
C++ support.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Right now, in hid_open it is checked if the connected devices have
"HIDClass" driver name. This is true for composite devices, but some
simple HID devices only have "Mouse" or "Keyboard" driver name.
One of devices that cannot be opened is Dell MS116t, but any mouse which
is not part of composite device can be affected.
With this change, one can enumerate and open these devices.
Signed-off-by: Kubicz, Filip <filip.kubicz@nordicsemi.no>
Modern Windows implementations don't allow opening HID devices in
READ/WRITE mode if they are claimed by the system. Examples of such
devices include keyboards and mice.
However, these devices can be opened without READ/WRITE permissions, in
order to allow sending and receiving feature reports.
If open_device() fails, retry without requesting READ/WRITE permissions.
This inverts the logic of the parameter to open_device().
It is a refactor of #44 by @pqu.
Signed-off-by: Sean Cross <sean@xobs.io>
Limit the size of the buffer passed to hid_get_manufacturer_string(),
hid_get_product_string(), and hid_get_serial_number_string() because
calling the underlying win32 functions with larger buffers causes them
to fail.
In the past, there was desire to make hid_open() open devices
exclusively, preventing devices from being opened more than once.
Unfortunately, recent versions of Windows have made this largely
impossible for many devices, as it appears that Windows itself is
holding certain HID devices open or preventing them from being
opened in exclusive mode.
This patch will always open devices in SHARED mode on Windows.
hid_read() and hid_read_timeout() now return the number of bytes copied,
instead of the number of bytes returned by GetOverlappekdResult() (which is
the maximum report size for the device). This limits the return value to
the requested length (buffer size), matching the behavior on other
platforms.
Create a new free_hid_device() function which takes care of all the
resources in hid_device which may need to be freed/released.
Reported-by: Johan Lindh <johan@linkdata.se>
Passing product_id=0 will match any product of a given vendor. This patch
makes it also possible to use vendor_id=0 to match any vendor for a given
product id.
Windows code added to Ludovic's patch by Alan Ott.
Windows will enumerate a device before the driver has been attached to
that device. This is problematic, and causes hangups on Windows 7
(possibly othes) when the device is opened before a driver is attached
and then closed. This patch makes sure that a driver has been attached
to the device before putting it in the enumeration list.
This adds the familiar autotools build system and associated documentation
for Linux, FreeBSD, Mac, MinGW, and Cygwin. The old Makefiles have been
kept, and where appropriate have been renamed Makefile-manual.
Thanks to Peter Stuge, Ludovic Rousseau, Xiaofan Chen, Alex Dupre, and
Segher Boessenkool for providing testing, review, and suggestions, and to
Ludovic Rousseau for providing patches which contributed to this commit.
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.
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.
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>
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>
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.
hid_read_timeout() will execute a blocking read up until a timeout has been
reached or data has been received.
This patch implements it on all platforms and comes from Urs Fleisch.
Commit log message by Alan Ott.
Signed-off-by: Urs Fleisch <urs.fleisch@gmail.com>
Tested-by: Alan Ott <alan@signal11.us>
This fixes the performance issue caused by calling CancelIo() when no data arrives in asynchronous (non-blocking) mode. Reported by Bill Good.
This new design also fixes the race condition causing lost packets that can happen if data comes between the time when the Event was checked (WaitForSingleObject()) and the CancelIo() call. Reported by Hans Van Leemputten.
The interface number is added to the hid_device_info struct. Since the
Linux/libusb implementation can't put the Usage and Usage Page in the
hid_device_info struct because it requires detaching the kernel driver, the
interface number is added instead so that users with composite HID devices
can differentiate between the interfaces on the device.
