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.
--
Bye, Peter Korsgaard
