On Fri Jun 19 21:59:14 2026 +0000, Elizabeth Figura wrote:
This seems risky; if we expose USB compatible IDs it's possible that something will break expecting this to be an actual USB device... Fair concern! The change doesn't make the device claim to be USB: its hardware id stays `WINEBUS\VID_xxxx&PID_xxxx` (not `USB\VIDsomething`), and it registers no `GUID_DEVINTERFACE_USB_DEVICE`, so nothing identifies or enumerates it as a USB device. Only its compatible-id fallback list gains the USB\\Class\_\* strings, which are the same ones a HID device's USB interface parent exposes on Windows (and that wineusb.sys already emits for the devices it enumerates).
For binding: it still binds winehid through `WINEBUS\WINE_COMP_HID`, and no INF in the tree matches USB\\Class\_\* (I checked winebus, winehid, input.inf, mouhid, winexinput, but let me know if I missed any), so the new ids never participate in matching. The only in-tree code that consumes a USB\\Class id is an application running its own CM_Get_Parent / SetupDi check against the HID device's parent, which is the case this fixes. Otherwise, I think the heavier alternative is to synthesize a real USB interface PDO so the parent is genuinely a USB node, but that's a larger change to winebus' single-PDO model and I kept this to the compat-id strings the app actually reads. If you'd prefer that direction, or you have a specific consumer the strings would mislead, I'll follow that. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11205#note_143713