> The important point is that the initial Get-Device-Descriptor request is > the same in all cases. Windows asked for a 64-byte transfer and treated > the 8-byte response from the low-speed device as a normal short packet.
I unfortunately don't have access to a hardware USB analyzer, but I installed a software USB sniffer on a Windows 2000 box to analyze the differences between the Windows 2000 and the Linux USB stack behaviours. The software USB sniffer doesn't output what happens before the SET_ADDRESS control request, so I can only speak about what happens next. Remember that the device under test is a low-speed USB 1.1 device. Windows 2000 issues 4 request (there are probably a GET_DESCRIPTOR(DEVICE) and a SET_ADDRESS before those): GET_DESCRIPTOR(DEVICE, 18 bytes) GET_DESCRIPTOR(CONFIG, 4 bytes) GET_DESCRIPTOR(CONFIG, full) SET_CONFIGURATION I hacked the Linux 2.6.7 USB stack (UHCI driver), and found out the following: The device works when those requests are issued: GET_DESCRIPTOR(DEVICE, 18 bytes) GET_DESCRIPTOR(DEVICE, 18 bytes) GET_DESCRIPTOR(CONFIG, 4 bytes) GET_DESCRIPTOR(CONFIG, full) or GET_DESCRIPTOR(DEVICE, 8 bytes) GET_DESCRIPTOR(DEVICE, 18 bytes) GET_DESCRIPTOR(CONFIG, 8 bytes) GET_DESCRIPTOR(CONFIG, full) or GET_DESCRIPTOR(DEVICE, 18 bytes) GET_DESCRIPTOR(DEVICE, 18 bytes) GET_DESCRIPTOR(CONFIG, 9 bytes) GET_DESCRIPTOR(CONFIG, full) but it fails with GET_DESCRIPTOR(DEVICE, 8 bytes) GET_DESCRIPTOR(DEVICE, 18 bytes) GET_DESCRIPTOR(CONFIG, 4 bytes) GET_DESCRIPTOR(CONFIG, full) or GET_DESCRIPTOR(DEVICE, 8 bytes) GET_DESCRIPTOR(DEVICE, 18 bytes) GET_DESCRIPTOR(CONFIG, 9 bytes) GET_DESCRIPTOR(CONFIG, full) It seems the device is really buggy. I've tried to mimic the behaviour of Windows XP from the traces that Steve posted (performing the 4 requests with buffer lengths of 64, 18, 9 and 255 respectively), and the device fails. Steve, could you get a trace from a low speed USB 1.1 device under Windows XP ? > The real test would be to see what Windows XP does with a device that > doesn't like this initial sequence. I'm not aware of any such devices, > but it wouldn't be surprising to learn that some do exist. When I tried > monkeying with a gadget driver (so that it failed to respond to the > initial 64-byte request) Windows 2000 simply refused to enumerate it at > all. > > I've already got a patch that does something like what we've seen. It > uses the current approach first, and if that fails it switches to the > Windows approach. Does this sound like a good thing to submit? The problem here is that the device doesn't complain about any of those sequences. All GET_DESCRIPTOR requests complete successfully, with valid answers, but the device fails *later*, when I try to send a vendor-specific request. So a patch that would try the current approach first and switch to the Windows approach if it fails wouldn't be of any use, as the first approach would succeed. I'm not even sure if we could find an enumeration algorithm which would work for all buggy devices. From the comments in the USB code, the first GET_DESCRIPTOR(DEVICE) requests only 8 bytes because some devices fail with more than 8, and from the comments in an earlier mail in this thread, the first GET_DESCRIPTOR(CONFIG) requests 9 bytes because some devices fail with 8 bytes. My device needs either more than 8 bytes for the first GET_DESCRIPTOR(DEVICE) or exactly 8 bytes for the first GET_DESCRIPTOR(CONFIG). I contacted the vendor, but I'm not sure if they will acknowledge the bug. Laurent Pinchart
pgpKdlwbEua0P.pgp
Description: signature
