On 8/28/21 1:46 PM, Rémi Bernon wrote:
On 8/27/21 10:55 PM, Rémi Bernon wrote:
- if ((status = IoRegisterDeviceInterface(device, &GUID_DEVINTERFACE_HID, NULL, &ext->u.pdo.link_name))) + if ((status = IoRegisterDeviceInterface(device, ext->interface_guid, NULL, &ext->u.pdo.link_name))) { ERR("Failed to register interface, status %#x.\n", status); break;
Any chance we could put the hidclass hunks in a separate patch?
...
That would cause the "internal" "xinput" PDO be momentarily listed in the HID device interface class, as a duplicate device with the gamepad, and although applications aren't supposed to see or use it. Not a big deal, bug probably not very nice.
I guess it could come first though.
Yeah, that's what I meant.
BTW I used the "standard" XUSB interface class there, but now that I think of it and now that I'm moving everything to "winexinput" maybe it's not the best idea to do that.
Is there a general strategy on how to define Wine-specific GUIDs? Should I just go get some randomly generated GUID and that's it? Doesn't it have to have a specific marker to tell that it's some Wine-specific one?
I don't think there is, no. Personally I like to use regular-looking numbers for Data1 so that it's clear it's not a Windows GUID and nobody needs to waste time looking it up (this is even more true in tests), but there's no requirement for it.