Windows version doesn't enumerate devices when exactly one is connected

[jm4R]

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_enumerate returns nullptr.

When I plug USB keyboard as a second device, hid_enumerate enumerates both - keyboard and UPS.

On Linux and exactly the same machine it works fine.

[Youw]

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)?

[jm4R]

driver_name is "Battery" which is weird as in windows device manager the device class shows "HIDClass" as expected.

[Youw]

And when you have two devices connected?

[todbot]

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/

[todbot]

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_enumerate just fine (see hidapitester output below, it's using hidapi@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.

[Youw]

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

[todbot]

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...

[jm4R]

@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 SetupDiEnumDeviceInfo is 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.

[jm4R]

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_GetHidGuid doc and tries to open it. I will try it and prepare a pull request if it will work.

[Youw]

I'm afraid, opening a device might cause issue, like described here: #225 (comment)
I'll take a look at this closely

[jm4R]

We already do this:
https://github.com/libusb/hidapi/blob/master/windows/hid.c#L411

It is being open with open_rw set to FALSE, maybe this doesn't make the issue. I won't change it.

[Youw]

Hmm, right, fair enough.

[jm4R]

The PR works for me, please review. I didn't use HidD_GetHidGuid directly as it would require linking to hid.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.