[Bug 59604] New: setupapi: CM_Get_Parent stub breaks USB HID device identification
http://bugs.winehq.org/show_bug.cgi?id=59604 Bug ID: 59604 Summary: setupapi: CM_Get_Parent stub breaks USB HID device identification Product: Wine Version: 11.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: setupapi Assignee: wine-bugs@list.winehq.org Reporter: Robert-Gerigk@online.de Distribution: --- CM_Get_Parent() in dlls/setupapi/stubs.c is a stub that always returns CR_NO_SUCH_DEVNODE. This prevents applications from navigating the device tree to find parent USB devices for HID devices. A .NET application (KNX ETS 6.4) uses the following pattern to identify a USB license dongle: 1. Enumerate HID device interfaces via SetupDiGetClassDevs 2. For each HID device, call CM_Get_Parent to find the parent USB device node 3. Read the parent USB device properties (VID/PID) 4. If matching, open the HID device Since CM_Get_Parent always fails, the application never identifies the dongle even though Wine correctly enumerates it as a HID device. A minimal implementation that maps HID child devices to their USB parent devices (by replacing the "HID\" prefix with "USB\" in the device instance ID and looking up the result in the registry) resolves the issue. Additionally, SETUPDI_EnumerateMatchingInterfaces in devinst.c adds devices to the device info set even when they have no matching device interfaces. This causes SetupDiEnumDeviceInfo to return phantom devices that are not present, breaking applications that assume device and interface indices are synchronized. I have patches ready for both issues. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59604 --- Comment #1 from Robert-Gerigk@online.de --- I noticed Rémi Bernon has been implementing cfgmgr32 device node functions in Wine 11.6 (CM_Locate_DevNode, CM_Get_Device_ID, CM_Open_DevNode_Key, CM_Get_DevNode_Registry_Property). CM_Get_Parent would be a natural next step in that series. My current patch uses a string-based heuristic (replacing "HID\" with "USB\" in the device instance ID), which works for the specific use case but does not match Windows real device tree navigation. Rémi, are you planning to implement CM_Get_Parent with proper device tree support as part of your cfgmgr32 work? If so, Id be happy to hold off on submitting my workaround and help test instead. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59604 Rémi Bernon <rbernon@codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com --- Comment #2 from Rémi Bernon <rbernon@codeweavers.com> --- Yes I was planning to get to it eventually, although I haven't yet looked closely. I think the function is mostly just a wrapper around some registry property but I'm not completely sure whether we set up that property on our devices to description their relations in the tree. If not, it would have to be done in ntoskrnl.exe as well (ideally by calling the cfgmgr32 functions to set the registry properties, but it could just update the registry directly). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59604 --- Comment #3 from Robert-Gerigk@online.de --- Thanks for the Feedback! I just looked at the code again, I think the fix would be to pass the parent DEVICE_OBJECT to enumerate_new_device() in handle_bus_relations() and store the parent instance ID as DEVPKEY_Device_Parent. Then CM_Get_Parent couldd just read that property via the cfgmgr32 functions you have already implemented. Would you be fine with me working on that, or would you prefer to handle it yourself as part of your cfgmgr32 work? Either way, I can submit the phantom device fix (SETUPDI_EnumerateMatchingInterfaces) separately since it is independent. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59604 --- Comment #4 from Rémi Bernon <rbernon@codeweavers.com> --- (In reply to Robert-Gerigk from comment #3)
Thanks for the Feedback!
I just looked at the code again, I think the fix would be to pass the parent DEVICE_OBJECT to enumerate_new_device() in handle_bus_relations() and store the parent instance ID as DEVPKEY_Device_Parent. Then CM_Get_Parent couldd just read that property via the cfgmgr32 functions you have already implemented.
Would you be fine with me working on that, or would you prefer to handle it yourself as part of your cfgmgr32 work? Either way, I can submit the phantom device fix (SETUPDI_EnumerateMatchingInterfaces) separately since it is independent.
Sure, feel free to have a try. I didn't work on it yet myself, and I can find other things to work on. Fwiw we'd also likely need DEVPKEY_Device_Child and DEVPKEY_Device_Siblings properties too. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla