On 7/16/22 03:41, Claire (@ClearlyClaire) wrote:
On Fri Jul 15 22:08:13 2022 +0000, **** wrote:
Zebediah Figura replied on the mailing list:
On 7/14/22 02:50, Claire Girka wrote: > From: Claire Girka <claire@sitedethib.com> > > Using SetupDiGetDeviceRegistryPropertyW rather than SetupDiGetDeviceRegistryPropertyA > in the test, because games use the former, and Windows returns the Container ID as a > WCHAR string either way. > --- > dlls/ntoskrnl.exe/pnp.c | 8 ++++++++ > dlls/ntoskrnl.exe/tests/ntoskrnl.c | 6 +++++- > 2 files changed, 13 insertions(+), 1 deletion(-) > > diff --git a/dlls/ntoskrnl.exe/pnp.c b/dlls/ntoskrnl.exe/pnp.c > index 71c03586897..e5c9b441b87 100644 > --- a/dlls/ntoskrnl.exe/pnp.c > +++ b/dlls/ntoskrnl.exe/pnp.c > @@ -318,6 +318,7 @@ static void enumerate_new_device( DEVICE_OBJECT *device, HDEVINFO set ) > BOOL need_driver = TRUE; > NTSTATUS status; > HKEY key; > + WCHAR *id; > > if (get_device_instance_id( device, device_instance_id )) > return; > @@ -353,6 +354,13 @@ static void enumerate_new_device( DEVICE_OBJECT *device, HDEVINFO set ) > return; > } > > + if (!get_device_id(device, BusQueryContainerID, &id) && id) > + { > + SetupDiSetDeviceRegistryPropertyW( set, &sp_device, SPDRP_BASE_CONTAINERID, (BYTE *)id, > + (lstrlenW( id ) + 1) * sizeof(WCHAR) ); > + ExFreePool( id ); > + } > + > start_device( device, set, &sp_device ); > } > This test [1] and MSDN documentation [2] imply we probably should be querying ContainerID before installing the function driver, though. [1] https://testbot.winehq.org/JobDetails.pl?Key=119104 [2] https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/adding-a-pnp-device-to-a-running-system _______________________________________________ wine-gitlab mailing list -- wine-gitlab@winehq.org To unsubscribe send an email to wine-gitlab-leave@winehq.orgI am not sure what the test shows, running the test under Wine returns similar results (although the queries appear to be performed twice), with the same IDs being queried, none involving `BusQueryContainerId` (0x5):
driver_pnp.c:136: Test failed: Unexpected ID query of type 0. driver_pnp.c:136: Test failed: Unexpected ID query of type 0x3. driver_pnp.c:136: Test failed: Unexpected ID query of type 0. driver_pnp.c:136: Test failed: Unexpected ID query of type 0x3.
Eh, right, that test is meaningless because we don't go through enumerate_new_device() for root PnP devices.
To my understanding, the documentation suggests that Windows queries all properties *before* saving those to the registry and installing the device driver, while Wine interleaves querying and storing in `install_device_driver`, and in the case of my patches, queries and stores the container ID after running `install_device_driver`.
Right.
So if I understand correctly, you're suggesting to move the ContainerID querying back to `install_device_driver`. However, as I explained earlier, I think we want the ContainerID to be re-queried in `enumerate_new_device` even if the driver is already installed (which seems to occur in the case of winebus HID devices across reboots and port changes when a Serial number is exposed), and my current implementation of ContainerID (not submitted so far) relies on this. Maybe the driver already being installed across reboots and ports is a bug, though.
Right, I was thinking it should be done unconditionally in enumerate_new_device() as in your v10. That should probably apply to the hardware and compatible IDs as well eventually.