-
Notifications
You must be signed in to change notification settings - Fork 396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need new backend for BLE under Windows #282
Comments
I think this may be relevant to you: The other thing that comes to my mind: is your device a Mouse-/Keyboard-like device? In other words - does hid_open_path falls-back to no read/write access ( |
My device is not the mouse-/keyboard-like device, I set the report descriptor to a custom report, and when I try to read write the device, the python program did not warn me with no read/write access.
This one is interesting, did the question mean that the product name can be seen like this Right now what I'm scared about is I did something wrong on the device side, so it would be better if anyone can test with their classic Bluetooth HID device. |
To verify your device, you could try using macOS version of the library (you'd need mac of course) or hidraw backend on Linux. |
What I'm scared of is I did something wrong for what Windows required. I had tested with Linux before and it can even get the product name of the BLE device. So my problem is really Windows specific |
Just checked DualShock4 controller connected via Bluetooth and can confirm that it is working:
Also checked Xbox Series Controller Model 1914 connected via Bluetooth LE: only
Tests are done on Windows 10 Version 1909. This is how it is seen in Windows "Bluetooth & other devices" screen: Here is control panel screenshot: Seems there is impossible to get "Xbox Wireless Controller XXXXXX" string for Bluetooth LE device via HID API. Also Bluetooth LE APIs are not exposed via classic IOCTLs and only usable via Windows.Devices.Bluetooth.GenericAttributeProfile WinRT API. See https://github.com/microsoft/Windows-universal-samples/tree/master/Samples/BluetoothLE/cppwinrt for example code. |
This looks like a potential alternative backend for Windows: I woundner if it works with BluetoothLE devices properly, i.e. so we could use Windows.Devices.HumanInterfaceDevice instead of Windows.Devices.Bluetooth. |
I tried this yesterday when I try to build an hidapi version with winrt API So right now I'm trying to build a version that uses winrt API to get the product string if the HidD_GetProductString return a null pointer |
That is
I believe that should be possible using Windows.Devices. API |
I think this function is related to hid_get_input_report instead of hid_read?
Then I'm not quite sure, as I am using the Windows.Devices.Enumerate.DeviceInformation API |
hid_read reads any input report from async queue, reports that device sends asyncronously (interrupt pipe). get_input_report(report_id, ...) gets a report with specific report ID from the device on demand. Functionally, GetInputReportAsync(UInt16) matches hid_get_input_report, and GetInputReportAsync() - hid_read.
Yeap, this looks right. |
I see
Well, this API didn't provide serial number string and manufacturer name. |
Have you tried to print all of Windows.Devices.Enumerate.DeviceInformation.Properties ? |
Yes, somehow it only got these 8 keys |
That's unfortuante. I guess as an alternative it should be possible to get/open a Windows.Devices.BluetoothDevice from Windows.Devices.Enumerate.DeviceInformation and ask for its SerialNumberString |
I don't think so. |
Also you can try these functions for Bluetooth LE device: https://docs.microsoft.com/windows-hardware/drivers/bluetooth/bluetooth-low-energy-functions |
Thx, I will check it later. |
More investigation gives me more info about HID device:
Those UUIDs are listed at https://www.bluetooth.com/specifications/assigned-numbers/ as 16-bit values. See "Service Discovery" spec for clarification. |
Okay, so the current API won't work with ble hid |
WinRT is available as part of Windows SDK. When you build environment is ready, you should nornally do: NOTE: I believe WinRT is designed more like C++ API (not a C API), and I'm not sure is it usable from C in general. |
Yeah, I know about this P.S. We need to keep using C because libraries similar to this is not using the dll file, they are using the source file directly |
@LeeChunHei you can do it but code will be creepy. Example: https://github.com/libsdl-org/SDL/blob/main/src/joystick/windows/SDL_windows_gaming_input.c |
Thanks, this example looks useful to me. |
Since we need to go this way only because WinAPI HID API doesn't work with BluetoorhLE devices, maybe it would be much easier to use this instead: |
I think it's a bit hard to use this to communicate with the ble hid device? |
I don't suggest using ble API for everything - only to get Manufacturer/Serial/Product strings if we detect it is a BleLE device. |
NOTE: we can only accept WinRT API as an alternative backend, not a replacement. |
No, from my test, I don't think we can communicate ble hid device with Win32API |
So we have two issues issues here:
|
I think @DJm00n tested that Bluetooth classic HID (DualShock4) can have the product string correctly shown. |
I see. Thanks for the clarifications. |
@mcuee afaik only Xbox Series Controller Model 1914 seen with VID:045E PID:0B13 (PID:0B12 over USB) can work over BLE connection (HID over GATT). Older versions are working via usual Bluetooth 4 (HID over L2CAP). You can see controller model number on the sticker in battery compartment. |
@LeeChunHei I have ESP32 devices as well but never really play with Bluetooth. Maybe I will try that as well in the future. |
@DJm00n Thanks. My one is the old model 1708 so it is not compatible with BLE then. |
This seems another difficult question that my question in OSR NTDEV forum got no answers. |
Oh, and BTW: I think there is absolutely no sense implementing winrt backend for HIDAPI in To be clear: it is possible/fairly easy to have both: pure |
XD, right now I'm kinda close to finishing the backend with WinRT with c only, but not doing any testing yet since I'm very busy now. |
It will allows other languages to integrate just fine. |
Do you have a WIP branch or something? |
Ah, no |
@Youw |
PR #309 should fix this issue. |
@LeeChunHei could you please test my PR #309? |
@LeeChunHei click to expand
hidapi main line git output: click to expand
|
Which ESP32 BLE HID FW are you using? I found a few here but I have never used Arduino (haha, do not laugh at me) or Espressif's ESP-IDF before. I only played a bit with MicroPython with the ESP32. Micropython example is not ready yet. |
@mcuee |
@DJm00n |
Thanks. I just downloaded ESP-IDF onto my Mac Mini M1 and then I can build the default BLE HID example. Unfortunately it does not seem to work on my cheap ESP32 board -- my Mac can not connected to it even though the device shows up as "ESP BLE HID2" from the Bluetooth Devices list.
|
@LeeChunHei I have changed the title to remove the "product name for Bluetooth classic HID in Windows 10" portion, as it seems to work well with the current HIDAPI codes, based on the testing results from @DJm00n . You can refer to my Logitech Bluetooth Mouse output which also shows that the current HIDAPI code is working. So that portion is probably just related to ESP32. |
@LeeChunHei Interestingly the ESP32 BLE HID device has no issues under my Windows 10 20H2 Dell Laptop. @DJm00n Output from #309 seems to show that it is working.
|
@LeeChunHei Your WinRT branch seems to work fine as well.
|
) As per MS, HidD_GetProductString/HidD_GetManufacturerString/HidD_GetSerialNumberString [doesn't work](https://docs.microsoft.com/en-us/answers/questions/401236/hidd-getproductstring-with-ble-hid-device.html) with Bluetooth LE (BLE) devices. Add special handling for BLE devices and fill `manufacturer_string`/`product_string`/`serial_number` using BLE-specific API. Fixes: #282
I am using the python wrapper of this library, pyhidapi
when I check the product_string of the Bluetooth HID device, it returns None.
I noticed that in windows this library is using HidD_GetProductString to get the name of the HID device.
So I asked in Microsoft community and they replied this function will not work on BLE device but will work on the classic Bluetooth.
However, it still not working after I change to use Bluetooth classic HID device.
Therefore, I would like to ask if anyone successfully gets the Bluetooth classic HID Device product string with Windows10 before.
Or I just messed up with some other stuff.
The text was updated successfully, but these errors were encountered: