Based on #696
- Add missing checks for zero/null arguments;
- Better management of error strings in case of failures;
---------
Co-authored-by: Megamouse <studienricky89@googlemail.com>
hid_read_error is a separate error function, that returns error status of hid_read/hid_read_timeout.
hid_read/hid_read_timeout is no longer changes internal buffer used by hid_error and it makes it safe to use hid_read/hid_read_timeout from a separa thread, concurently with other device functions.
-Add reconstruction logic of const padding bytes at the end of a report for devices which don't use ReportIDs
-Enhanced padding logic to distinguish between byte and bit padding.
-Add a new test case for Razer Cobra mouse `1532_00A3_0002_0001` which has a completly con feature report of 90 bytes.
-Modified expected report descriptor reference file `045E_02FF_0005_0001_expected.rpt_desc` to include additional padding bytes.
According to documentation, the system reserves the right to run
WriteFile synchronously, even if FILE_FLAG_OVERLAPPED is set,
so `bytes_written` needs to be taken from `WriteFile` directly in that case.
`hid_send_output_report` sends report over control pipe, unlike existing `hid_write` which would send the data on the first interrupt OUT endpoint, if one exists and only falls back to control pipe.
This is unsafe because the event is auto-reset, therefore the call to
WaitForSingleObject() resets the event which GetOverlappedResult() will
try to wait on.
Even though the overlapped operation is guaranteed to be completed at
the point we call GetOverlappedResult(), it will still wait on the event
handle for a short time to trigger the reset for auto-reset events. This
amounts to roughly a 100 ms sleep each time GetOverlappedResult() is called
for a completed I/O with a non-signalled event.
In the context of HIDAPI, this extra sleep means that callers that loop
on hid_read_timeout() with timeout=0 will loop forever, since the 100 ms
sleep each iteration ensures ReadFile() will always have new data.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Sam Lantinga <slouken@libsdl.org>
Win32 HID API doc says: For USB devices, the maximum string length is 126 wide characters (not including the terminating NULL character).
For certain USB devices, using a buffer larger or equal to 127 wchars results in successful completion of HID API functions, but a broken string is stored in the output buffer. This behaviour persists even if HID API is bypassed and HID IOCTLs are passed to the HID driver directly (IOCTL_HID_GET_MANUFACTURER_STRING, IOCTL_HID_GET_PRODUCT_STRING, etc).
So, the buffer MUST NOT exceed 126 wchars.
windows: refactor ULONGLONG hid_internal_get_info(...) -> hid_internal_detect_bus_type_result hid_internal_detect_bus_type(...)
hid_internal_detect_bus_type is now only responsible for detection of the bus type; rename it accordingly. Also, mixing an internal flag and DEV_INST into an ULONGLONG retval feels kinda hackish; use a cleaner approach instead (add an internal flag to help distinguishing between BLUETOOTH and BLE devices, then clear it once we are done).
* Invert preprocessor condition, as the Microsoft compiler seems to be the special case - not the other way around
* Removed redefinition of typedef 'PHIDP_PREPARSED_DATA' in hidapi_hidsdi.h to match the original hidsdi.h
As reported in #630
This is efficient for Xbox Common Controller class (XUSB) devices like Xbox 360 or Xbox One controllers that are missing serial number via usual HID API.
On some compilers an empty definition (e.g. -DHID_API_EXPORT)
means the same as `=1` (i.e. -DHID_API_EXPORT=1), but the HID_API_EXPORT macro should be
empty in static library build case.
Having a separate compiler definition flag solves that issue.
- native implementations for hidraw/libusb/macOS;
- HID Report Descriptor reconstruction from HIDP_PREPARSED_DATA on Windows;
- unit-tests for some known devices for `hid_winapi_descriptor_reconstruct_pp_data`;
- support for ASAN builds (mainly to check the `hid_winapi_descriptor_reconstruct_pp_data`/its unit-tests;
Don't mark API functions with __declspec(dllexport) when building a static library on Windows.
Enforced by CMake builds.
For other builds a compile definition is available.
Related: #480
- new API function: `struct hid_device_info * hid_get_device_info(hid_device *dev);` to get `hid_device_info` after the device already opened;
- reused existing implementation on Windows and macOS from enumeration routines to have the implementation;
- refactored libusb implementation to have a shared routine for `hid_enumerate` and `hid_get_device_info`;
- refactored hidraw implementation to have a shared routine for `hid_enumerate` and `hid_get_device_info`;
Resolves: #431Closes: #164Closes: #163
- make the behaviour of methods which set hid_error more consistent;
- make the documentation and the implementation of hid_error consistent and safe;
- windows: add global error implementation;
Co-authored-by: Julian Waller <git@julusian.co.uk>
- a straight-forward build matrix for Appveyor;
- MSBuild builds with Github Actions;
- Visual Studio 2022 support for `.sln` (toolset v143);
- gather Windows build artifacts with Github actions;
- separate HID declarations for non-DDK build into re-usable headers;
- refactor initialisation/deinitialisation of HIDAPI;
- make all the comments consistent (C-style only);
Fixes a segfault that happens when hid_open_path is called on a previously disconnected device.
This is a regression caused by:
b600727 - Win32: Fix memory leak in `free_hid_device` (#361)
Co-authored-by: Megamouse <studienricky89@googlemail.de>
- It appears when the numbered reports aren't used,
WinAPI returns size of the report excluding the data[0] which contains 0,
as an indication that numbered reports aren't used;
Explicity count that byte in the result.
Fixes: #328
Deleted DDK build scripts, support files and documentation for it,
as it wasn't working of-the-box with recent tool-sets from MS anyway.
Still keeping `HIDAPI_USE_DDK` macro in the code,
as it still _can_ be used if the build configuration is setup properly.
Resolves: #49
