13 Jul
2022
13 Jul
'22
6:22 p.m.
On Wed Jul 13 18:15:56 2022 +0000, **** wrote:
Zebediah Figura replied on the mailing list:
On 7/13/22 12:47, Claire (@ClearlyClaire) wrote: > On Wed Jul 13 17:06:25 2022 +0000, **** wrote: >> Zebediah Figura replied on the mailing list: >> \`\`\` >> On 7/13/22 01:29, Claire (@ClearlyClaire) wrote: >>> On Wed Jul 13 03:00:55 2022 +0000, **** wrote: >>>> Zebediah Figura replied on the mailing list: >>>> \`\`\` >>>> On 7/12/22 16:12, Claire (@ClearlyClaire) wrote: >>>>> On Tue Jul 12 18:48:28 2022 +0000, **** wrote: >>>>>> Zebediah Figura replied on the mailing list: >>>>>> \`\`\` >>>>>> On 7/12/22 13:01, Claire Girka wrote: >>>>>>> From: Claire Girka <claire@sitedethib.com> >>>>>>> >>>>>>> --- >>>>>>> dlls/ntoskrnl.exe/pnp.c | 8 ++++++++ >>>>>>> 1 file changed, 8 insertions(+) >>>>>>> >>>>>>> diff --git a/dlls/ntoskrnl.exe/pnp.c b/dlls/ntoskrnl.exe/pnp.c >>>>>>> index e12e46f94f1..77d879a07a9 100644 >>>>>>> --- a/dlls/ntoskrnl.exe/pnp.c >>>>>>> +++ b/dlls/ntoskrnl.exe/pnp.c >>>>>>> @@ -880,6 +880,7 @@ NTSTATUS WINAPI >>>>>> IoRegisterDeviceInterface(DEVICE_OBJECT *device, const GUID *cla >>>>>>> struct wine_rb_entry *entry; >>>>>>> DWORD required; >>>>>>> HDEVINFO set; >>>>>>> + WCHAR *id; >>>>>>> >>>>>>> TRACE("device %p, class_guid %s, refstr %s, symbolic_link %p.\n", >>>>>>> device, debugstr_guid(class_guid), >>>> debugstr_us(refstr), symbolic_link); >>>>>>> @@ -913,6 +914,13 @@ NTSTATUS WINAPI >>>>>> IoRegisterDeviceInterface(DEVICE_OBJECT *device, const GUID *cla >>>>>>> return STATUS_UNSUCCESSFUL; >>>>>>> } >>>>>>> >>>>>>> + if (!get_device_id(device, BusQueryContainerID, &id) && id) >>>>>>> + { >>>>>>> + SetupDiSetDeviceRegistryPropertyW( set, &sp_device, >>>>>> SPDRP_BASE_CONTAINERID, (BYTE *)id, >>>>>>> + (lstrlenW( id ) + 1) * sizeof(WCHAR) ); >>>>>>> + ExFreePool( id ); >>>>>>> + } >>>>>>> + >>>>>>> data->DevicePath[1] = '?'; >>>>>>> TRACE("Returning path %s.\n", debugstr_w(data->DevicePath)); >>>>>>> RtlCreateUnicodeString( &device_path, data->DevicePath); >>>>>> Why do we need this? >>>>>> _______________________________________________ >>>>>> wine-gitlab mailing list -- wine-gitlab@winehq.org >>>>>> To unsubscribe send an email to wine-gitlab-leave@winehq.org >>>>>> \`\`\` >>>>> I would need to investigate more, but the property isn't properly >>>> exposed without that change. >>>>> >>>> Please do; I don't think it should be necessary, and we'd rather fix it >>>> the right way upstream if not. >>>> _______________________________________________ >>>> wine-gitlab mailing list -- wine-gitlab@winehq.org >>>> To unsubscribe send an email to wine-gitlab-leave@winehq.org >>>> \`\`\` >>> I investigated, and my understanding is that `install_device_driver` >> in `dlls/ntoskrnl.exe/pnp.c` is only called the first time the HID >> device is registered. This means that changing `install_device_driver` >> alone is not sufficient to update the `ContainerID` if it changes, nor >> to register a `ContainerID` at all if the device was ever used before >> the change is implemented. I am not sure where the best place to update >> the `ContainerID` should be. >>> >> Why is it possible for the container ID to change? >> _______________________________________________ >> wine-gitlab mailing list -- wine-gitlab@winehq.org >> To unsubscribe send an email to wine-gitlab-leave@winehq.org >> \`\`\` > That is a good question. Maybe it shouldn't. But one reason I can think of is that we may change how we assign ContainerIDs (for now we don't, I currently have patches that work reasonably well, but if we change approaches, we would change how we assign them). > > Another reason is that the container device (the USB hub itself) does not expose a serial ID, but its HID child device seems to. Therefore, Wine will reuse the same devnode across sessions and across ports for the HID device, while the other child devices may not be matched the same way (other than querying the sibling HID device, which seems unreasonable to do in general). > > (For reference, Windows does not seem to see or use that serial number in any way, and creates a different device node depending on the USB port the gamepad is plugged into.) > Well, sure, the container ID for the "same" device might change across boots, for one reason or another. But once the device is plugged in and enumerated I wouldn't expect the container ID to change, should it? In which case we should only need to query it once, and I wouldn't expect it to matter when. _______________________________________________ wine-gitlab mailing list -- wine-gitlab@winehq.org To unsubscribe send an email to wine-gitlab-leave@winehq.org
Yes, once plugged in, the Container ID does not change. In earlier versions of the patchset, the Container ID was queried at driver installation (a step that is not re-executed on reboots and re-plugs if the same identifiers get reused by Wine) and, because that wasn't enough, at each interface registration (which was needlessly often). I believe the current version of the patch, which does it when enumerating a new device, fits your expectations.