Windows: Bluetooth and WriteFile API issues #513
Labels
No labels
3rdparty
Android
API
Author does not respond
bsd
bug
build system/CI
ci-virtual-device
CMake
Contributions Welcome
Core
dependencies
device-specific
documentation
don't_merge
duplicate
enhancement
Example
Haiku
hidraw
hotplug
info required
invalid
libusb
macOS
Misc
Not an issue
question
Release
Test
Test GUI
Windows
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-libusb/hidapi#513
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Looks like Windows Bluetooth drivers have issues with sending output reports with
WriteFile.Need to investigate this and try to use
HidD_SetOutputReportas a fallback.https://stackoverflow.com/questions/29480144/hidapi-sending-packet-smaller-than-caps-outputreportbytelength
https://social.msdn.microsoft.com/Forums/ie/en-US/834d2cf2-672d-424b-a126-dbc69f3f75a2/hiddsetoutputreportwritefile-bluetooth-low-energy-windows-81
Related https://github.com/libsdl-org/SDL/issues/7224
https://www.bluetooth.com/specifications/specs/human-interface-device-service-1-0/
https://stackoverflow.com/questions/63115984/what-is-the-difference-between-read-report-get-input-report-write-report
https://www.usb.org/document-library/device-class-definition-hid-111
The later only proves that we cannot unconditionally replace
WriteFilewithSetOutputReport, I guess.As for bug "WriteFile() doesn't work correctly" I think we could have a per-device, WinAPI-specific option to use
HidD_SetOutputReportashid_writeimplementation.Or do you think we can predict for which devices
WriteFileis going to fail? Is it known to be specific to BLE or smth?As far as I understand, in BLE case API works like this:
WriteFile->IOCTL_HID_WRITE_REPORT->Data Output->GATT Write Without Response->ATT_OP_WRITE_CMD->0x52HidD_SetOutputReport->IOCTL_HID_SET_OUTPUT_REPORT->Set_Report (Output)->GATT Write Characteristic Value->ATT_OP_WRITE_REQ->0x12According to the HIDS spec
Read/Write/Write Without Responseare mandatory forReport: Output Report Typecharacteristic.But seems some devices are not declaring
Write Without Responseand in resultWriteFilecall is failing (for example Stadia Controller with new "Bluetooth mode" firmware is known to have such issues).I'll try to debug this to find out more.
Would be great to figure out if it is possible to check its support over WinAPI before trying to use
WriteFile(e.g. if it is a part of some descriptor, or just device fails to respond on a specific command).See also https://github.com/signal11/hidapi/issues/378
For DS4 controllers specifically: a fix has been submitted to the active DS4Windows fork that switches BT output from WriteFile (interrupt pipe) to HidD_SetOutputReport (control pipe): https://github.com/ds4windowsapp/DS4Windows/pull/9
Confirmed working on Realtek RTL8761B (TP-Link UB500) + Windows 11. The transport mapping analysis by @DJm00n in this issue was key to understanding the root cause — the unacknowledged interrupt path silently drops reports on these adapters.
Considering that we have a hid_send_output_report and this is not really a HIDAPI issue (a Windows Driver/Device-specific issue) I'd call out to close it w/o any specific fixes to HIDAPI itself (let it be as thin proxy as feasible), and, maybe, have a NOTE about this somewhere.
Either the document or Wiki.
https://github.com/libusb/hidapi/wiki/Known-Issues#bluetooth-hid_write-may-silently-drop-output-reports-on-some-ble-adaptersdevices