requesting device descriptor: specifying the correct value for wLength

[erdmann]

Hallo,

according to the Windows USB core team blog:
http://blogs.msdn.com/b/usbcoreblog/archive/2009/10/31/how-does-usb-stack-enumerate-a-device.aspx

there are some (older) devices that require that 64 bytes is specified for wLength in the setup packet to read the device descriptor (maybe because they also require that 64 bytes is specified as max packet size for as long as the device descriptor is not yet received ...).
Does anyone have any practical experience if these devices will still restrict themselves to sending 18 bytes (the device descriptor size) even though 64 bytes was specified for wLength ?
The USB 2.0 spec says that the device should limit itself to 18 bytes (chapter 9.4.3) and send a short packet as the (possibly first and) last packet but I have my doubts with USB with regard to reality ...

As always: any help greatly appreciated.

Lars

[Jan Axelson]

I don't know the answer though a device can only send data in response to an IN packet, so if maxpacketsize is < 64, the host likely will stop requesting data after receiving at least 18 bytes.

Why is this a concern? The host can ignore any unneeded data, and devices are required to drop the previous request on receiving a new Setup packet.

[Barry Twycross]

My driver always requested 8 bytes of the descriptor as the first request. I can't remember many, if any devices which failed that. Certainly, no devices built in the last 10 years.

[erdmann]

Alex:
The problem is that it is not obvious what to set for maxpacketsize until you have received the device descriptor.
Full speed allows different values for maxpacketsize. The Windows stack initially picks 64 bytes (the maximum). But the result seems to be that for these broken devices they then expect wLength to be 64 bytes as well. On the other hand, these broken devices do not accept anything else but maxpacketsize = 64 on the first get device descriptor request (as far as I understand it).
The Windows USB blog also says that some devices "babble". I assume they mean that the device will send 64 bytes if 64 bytes is specified for wLength even though they should know better and send only 18 bytes on a get device descriptor request. I am afraid that memory will be overwritten.

I also don't understand how a host could ignore any data. Currently I set up a transfer where I specify a receive buffer size of 18 bytes. This is effectively what's put into the transfer descriptor of the USB host controller. Nonetheless I specify 64 bytes for wLength. Do you mean that by "the host could ignore any data" ?

Barry:
Initially I did as you proposed and I specified wLength=8 and I consequently picked 8 bytes as maxpacketsize because that matched just fine and that worked for all the devices that I own. After reading the Windows USB blog I understood that this does not work for some broken devices even though of course it should. Maybe I shouldn't bother with broken device FW. I don't intend to support 10 year old USB devices ...

[Jan Axelson]

By "ignore any unneeded data," I meant for example, that if the host asks for 8 bytes and the device returns 18, the host can use the 8 bytes as intended and ignore the final ten bytes.

[Barry Twycross]

Barry:
Initially I did as you proposed and I specified wLength=8 and I consequently picked 8 bytes as maxpacketsize because that matched just fine and that worked for all the devices that I own. After reading the Windows USB blog I understood that this does not work for some broken devices even though of course it should. Maybe I shouldn't bother with broken device FW. I don't intend to support 10 year old USB devices ...

I had direction that I didn't need to support broken devices, so there may have been some out there that didn't work with the system, but that was never important enough for us to change the driver. The driver was good enough for 10s of millions of systems. I know Windows did things differently, but they started earlier than I did, so tried hard to support the very first devices which existed. A lot of those early devices were badly broken.