Windows version doesn't enumerate devices when exactly one is connected #234
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#234
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?
I don't know if this is coincidence, but this is my case:
I plug UPS HID device (CyberPower or APC) as an only HID device in the whole system, and
hid_enumeratereturnsnullptr.When I plug USB keyboard as a second device,
hid_enumerateenumerates both - keyboard and UPS.On Linux and exactly the same machine it works fine.
I assume you're using build 0.10.1.
Can you step-trace a "single device" scenario with a debugger and tell what do you get from SetupDiGetClassDevsA/SetupDiEnumDeviceInterfaces (or after those)?
driver_name is "Battery" which is weird as in windows device manager the device class shows "HIDClass" as expected.
And when you have two devices connected?
Yes, I believe on Windows, with the HID Battery driver, that removes it from the list of devices hidapi can access. (as what happens to gamepads) http://batcmd.com/windows/10/services/hidbatt/
I just tested an APC Back-UPS ES 550 on Windows 10 Pro. It appears as both a HID device and as a "Battery" to device driver (see screenshot below). And it appears to hidapi's
hid_enumeratejust fine (seehidapitesteroutput below, it's usinghidapi@0.10.1). Perhaps you have an additional, non-Microsoft driver on the device?Oh, wait, but I see, the issue is that if the UPS is the only HID device. Hmmm.
I think the problem comes if you'd have only this UPS connected, and no other HID devices in the system.UPD: this conversation looks weird, when we both edit our messages :D
Yes I understand that better now. :) Trying to figure out how to test this since RDP just decided to stop working with a recent Win10 update...
@Youw when I plug the keyboard and the mouse in, all iterations returns "Keyborad" as a device name. Something is definetely wrong in this code. I found old, open but abandoned pull request that claims that the index passed to the
SetupDiEnumDeviceInfois wrong:https://github.com/signal11/hidapi/pull/291/files/f453bda38ff17ea28b7b1d59afd8d09e74e5efb5#diff-8162c58f4630fb0f3a6a21f2e094e883L354
It seems that after simillar change the driver_name shows more apriopriate values to the ones that are shown in Windows Device Manager. To sumarise that, it looks like
hid_enumerate enumerates all USB devices if the first on the list is HIDClass or Mouse or Keyboard
This is coincidence that the code works with my UPS because

SetupDiEnumDeviceInfo(device_info_set, device_index, &devinfo_data);after the "quickfix" still returns "Battery", but we should somehow retreive the value which is shown by the Windows device manager as on the screenshot:This way, we can expect that we could get rid of the "Keyboard" and "Mouse" exceptions, because for those devices the device manager also shows "HIDClass" value. Yet, I am not very familiar with WinApi so I don't know (yet) how to retrive it using WinApi.
How about solution straight from Microsoft:
https://github.com/microsoft/Windows-driver-samples/blob/master/hid/hclient/pnp.c#L32
?
It is similar but instead of checking device class name, it just uses
HidD_GetHidGuiddoc and tries to open it. I will try it and prepare a pull request if it will work.I'm afraid, opening a device might cause issue, like described here: https://github.com/libusb/hidapi/issues/225#issuecomment-751252471
I'll take a look at this closely
We already do this:
https://github.com/libusb/hidapi/blob/master/windows/hid.c#L411
It is being open with
open_rwset toFALSE, maybe this doesn't make the issue. I won't change it.Hmm, right, fair enough.
The PR works for me, please review. I didn't use
HidD_GetHidGuiddirectly as it would require linking tohid.lib. The hard-coded GUID is the same with the one returned by this function which means the enumeration already filters only HID-class devices.