On Fri, Sep 13, 2024 at 05:39:21PM +0200, Peter Korsgaard wrote: > On 9/11/24 03:32, Vodicka, Michal wrote: > > > Hmm, very odd. How are you testing this on the host side? > > > > We just attach the device and check the registry values created by OS > > for our device. As > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_XXXX&PID_YYYY&MI_NN\<device_instance>\Device Parameters. > > When it works our extended properties are created there. > > > > We check the communication using USB analyzer which clearly shows > > wValue bytes are in opposite order than documented. This is SETUP > > packet captured: > > > > Offset 0 1 2 3 4 5 6 7 > > 0x000 C1 A1 02 00 05 00 0A 00 > > > > As you can see, this is interface request and out interface number was > > 2 which is in the low byte of wValue. > > OK, annoying. I am traveling for conferences this/next week so I cannot > verify here, but presumably you are correct. Do you perhaps have a more > complete capture you can share? > > > > > > > Could it be that you are running into the WinUSB bug described here: > > > > No. The mentioned bug is in wIndex and out problem is wValue. Also, > > MSOS descriptors are read before WinUsb is even run. > > Ahh yes, indeed. > > > > What Windows version were you using and have you used USB analyzer to > > check the communication? > > It's been a while, but I believe Windows 10. In the end I ended up shuffling > the interfaces around so the one with the MSOS descriptors was interface 0 > for better compatibility, so it is possible that something went wrong with > my interface != 0 tests. > > If so, then I am fine with reverting, but we should probably add a comment > explaining that the documentation is wrong. Ok, Michal, can you add some text tothe changelog and send a v2 for this? thanks, greg k-h
