Hi Alan, > I've got a patch that's almost ready for submission, to change the way USB > devices are initialized. The trickiest part is determining the maxpacket > value for endpoint 0. The number is fixed at 8 for low-speed and 64 for > high-speed devices, but for full-speed devices it can be any power of two > between 8 and 64. And of course, without knowing the correct value it's > impossible to transmit any messages longer than 8 bytes.
[snip] > The patch has been tested and it works. In particular, Sony camcorders > work with the Windows scheme but not with the Linux scheme. Probably > other devices will act similarly; it's common for vendors to test only for > Windows compatibility and not for compliance with the USB spec. I ran across such a device not so long ago. Could you post your patch (or send it to me directly) so that I could test it ? > Clearly we should support both schemes. One thing my patch does is change > the total number of tries (SET_CONFIG_TRIES) from 2 to 4, trying the Linux > scheme twice and the Windows scheme twice. > > The question is, in what order should the schemes be tried? The > conservative approach would be to use the Linux scheme twice, then the > Windows scheme twice. But maybe that's not such a good choice; the Sony > camcorders respond to the 8-byte GET-DEVICE-DESCRIPTOR request by trying > to send the entire descriptor, thereby causing a Babble error. With a VIA > host controller this would ruin any chance of using the device. > > Other possibilities are to try the Windows scheme twice, then the Linux > scheme twice, or to alternate. Any suggestions? Well, the problem I experienced was that the device responded correctly to both the Linux and the Windows scheme, but failed to respond to device-specific requests afterwards if the Linux scheme was used for enumeration. There was no way to detect if the device would work correctly at enumeration time. This means that the Windows scheme should be tried first, but we could also consider that the device is too broken to be supported. I notified the vendor but got no answer. Laurent Pinchart
pgpMmfukOiowr.pgp
Description: PGP signature
