hid_enumerate with hidraw backend returns lots of duplicate hid_device_infos #298
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#298
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?
Calling
hid_enumeratewith the hidraw Linux backend returns lots of duplicatehid_device_infos for the same device. I have to filter out duplicates by comparing the paths of the devices: https://github.com/mixxxdj/mixxx/pull/4054/files/6dd77b1fa61a2101e2dfac7cb7af85bf5eab168b#r663541357Do those devices have the same usage/usage_page pairs? Have you tried the same device on Windows?
Some do, some do not. Here is the output from Mixxx:
I have not tested these devices on Windows.
This is unexpected.
That is expected. That is the only way to check supported usage/usage_page-s of the device - report same device multiple times with the same path but different usage/usage_page pair
I see.
Interesting, I have not seen such issue under Windows 10 Dell PC and macOS (Mac Mini M1). But I have not done much testing on Linux side (my Raspberry Pi 400 is my Linux computer now).
This seems to occur on Windows too:
https://mixxx.discourse.group/t/cant-find-midi-output-controller-to-link-to-qlc/22751/4
@Be-ing It will be good to post the output of hidtest and the report descriptors (eg: under Linux or macOS). That may give some clues about the devices. Windows will create multiple devices with each for TLC (top level collections) and may even have some virtual device created on top.
Windows: https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/top-level-collections
@Be-ing It seems that it is not really an issue under Windows to have "multiple individual enabled devices for my singular mouse and keyboard". That is kind of expected under windows with devices with multiple TLCs, same for hidraw and macOS.
Maybe Mixxx code has wrong assumptions in this asepct.
Relevant discussion: https://github.com/libusb/hidapi/issues/287
Perhaps, but besides potential functional implications, there is an issue of user confusion showing the same device multiple times.
That you can not change. hidapi is designed this way. You have to change mixxx.
I already did: https://github.com/mixxxdj/mixxx/pull/4054/commits/5c582575a06f28e9c42b1261f5b475024c0f186b
But I wasn't sure if the problem was in Mixxx's use of hidapi or in hidapi.
In order to debug, please post the output of hidapi hidtest and the report descriptors.
@Be-ing As @Youw mentioned, if the device does not have the "same usage/usage_page pairs", then the behavior is not expected with Linux hidraw backend. Then that could be a hidapi bug. Please post the output of hidtest and the report descriptor to debug the issue with hidraw.
Similar for Windows, if the device is listed in Windows Device Manager as different device due to fact that is has multiple TLCs, then it will be listed by HIDAPI as multiple devices and that is expected. If that is not the case, then it could be a HIDAPI bug. Again please post the output of hidtest under Windows and the HID report descriptors of the device (using Linux or macOS as it is difficult to do under Windows)
I did not notice the issue on Windows; a user on the Mixxx forum did. I think it's too much to ask that user to build hidtest to investigate this. It would help if there were builds of that available.
I just created a snapshot here with VS2019 and MinGW-w64 (MSYS2 distro), both 32bit and 64bit binaries of hidtest and libhidapi.dll are included. Take note this is just my fork and not official.
https://github.com/mcuee/hidapi/releases/tag/V27July2021
It would be nice to automate that with GitHub Actions.
@Be-ing Good idea.
@Youw please check if this can be done for different OS. Thanks.
On the other hand, under Windows, it is not easy to dump the hid report descriptors, so the user may need to use Linux or macOS. But anyway, another simple method is to check Windows Device Manager to see if the device is listed in multiple entries, then compare with the hidtest output.
#315
If you want that to work any platform (Windows) you should not assume device uniqueness (by the functionality) by the device path, but rather by the device VID+PID+USAGE+USAGE_PAGE.
On the other hand, I see your previous message, where you have the same device with the same VID+PID+USAGE+USAGE_PAGE combination listed multiple times, this is the first time I see such thing.
I agree that the output of
hidtesttool should be of help.VID+PID+USAGE+USAGE_PAGE may not be enough, path (or interface) is also needed as seen with the hidraw backend and my Logitech USB Receiver.
VID+PID+SERIAL_NUMBER+USAGE+USAGE_PAGE ?
Yes that will be good if the device have unique serial number. But that is not guaranteed.
@Be-ing @uklotzde
https://github.com/mixxxdj/mixxx/pull/4054#issuecomment-912897365
@uklotzde Just wondering if you can comment on this hidapi issue with regard to the Duplicate HID device under Linux hidraw backend. Please post the output of "lsusb -vvv" and "hidtest" (from hidapi) under Linux about your device (Traktor Kontrol S4 MK3). Thanks.
lsusb output for Kontrol S4 Mk3: https://github.com/systemd/systemd/issues/20533#issuecomment-907358491
@Be-ing Unfortunately the lsusb output is not good enough as the HID report descriptor is not listed.
HID report descriptors for Kontrol S4 Mk3:
@Be-ing Thanks. Now we need the output of "hidtest-hidraw" of this device to see what is the problem.
I have been working on reverse engineering the HID traffic between the Kontrol S4 Mk3 and Traktor this week in a Windows VM so I have that set up. I installed the latest Mixxx main branch build and forwarded the Kontrol S4 Mk3 to the VM. It appears this issue does not affect Windows, at least not with the Kontrol S4 Mk3. This is what I see in the log regarding HID devices:
Here is the hidtest output on Windows:
@Be-ing Your hidtest-hidraw output is good. Indeed it shows the problems.
Eg: two duplicate entries here.
And 4 duplicate entries here:
@Be-ing
As for the hidapi-libusb output under Linux, it seems to be a bit strange:
Usage (page): 0x0 (0xff01)but that is not related to this issue.As for your device under Windows, indeed I think it will not be affected as Windows treat the whole device (with single top level collection based on the report descriptor dump) as a single HID device.
Ref: Top-Level Collections under Windows: Microsoft defines a top-level collection as a HID collection that is not nested within another collection.
https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/top-level-collections
This seems to be affecting macOS too:
https://github.com/mixxxdj/mixxx/pull/4243#issuecomment-911503659
It will be good to ask the user to post the output of "hidtest" and "USB Prober". USB Prober can be used to dump the hid report descriptor under macOS.
USB Prober App download: https://ww5.touch-base.com/documentation/USBMacProber.htm
The 10.7.3 version still works on my Mac Mini M1 (Big Sur ARM64).
https://ww5.touch-base.com/downloads/MacProber/USB_Prober_Mac_OS_X_10.7.3.zip
Last version from IOUSBFamily 10.9.4
USB Prober_10_9_4.app.zip
https://newbedev.com/how-can-i-install-usb-prober-from-the-developer-sdk-on-mac-os-x
Source codes of USB Prober is here. Unfortunately it seems to me later IOUSBFamily becomes close source.
https://opensource.apple.com/tarballs/IOUSBFamily/
https://newbedev.com/how-can-i-install-usb-prober-from-the-developer-sdk-on-mac-os-x
IORegistryExplorer.app is more update and you can download.
Lastest release version is from Additional_Tools_for_Xcode_12.5. It can be used to dump the HID Report Descriptor but it does not have the capability to parse the report.
@Youw Now that the info under Linux is provided by Be-ing. Please take a look at the info and see how to further debug the issue under Linux.
I apologise for not getting back to this for so long.
I've checked the logs and have a working theory of what's wrong going on here (spoiler - a HIDAPI issue).
To check my theory, would be nice to get the output of
hidteston macOS as well for the same device (17cc:1720).@Be-ing any chance you could provide that now?
Sorry, I don't have access to any computers running macOS currently.
What about Windows?
Will you be able to use the latest master's
hidtest(and you'd have to modify it a bit) to print the output of hid_get_report_descriptor ? On Windows it would likely give a bit different output than you've already provied from a Linux machine (due to Windows Report Recostruction mechanism from PP Data).And the HID Descriptor output you've provided earlier - if you could provide it in raw hex format I'd appreciate it, so I can experiment the fix on it.
I have a Windows VM I could use to run
hidtestif you make a build with the modifications you alluded to.I've just checked - no changes to hidtest required. I've already applied those some while ago.
Simply run the
hidtestfrom latest master on both Windows and Linux/hidraw.@Be-ing
Any update on this topic?
@Be-ing see if you could test #601