On Sat Jul 16 08:41:48 2022 +0000, Claire wrote:
I 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.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`. 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.
I have decided to move the querying of `BusQueryContainerID` before the (conditional) call to `install_device_driver`. I doubt this changes anything in practice, especially in the case where the driver is already installed, but this is closer to what Windows does and this does not break my use case.