On Fri, Oct 08, 2004 at 12:08:55PM -0400, Alan Stern wrote:
> 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.
>
> The current scheme (the "Linux" scheme) goes like this:
>
> Reset the device
> Set endpoint 0 maxpacket to {8, 8, 64} for {low, full, high}-speed
> Send SET-ADDRESS (an 8-byte SETUP with no message body)
> Send 8-byte GET-DEVICE-DESCRIPTOR request; the bMaxPacketSize0
> value is stored in the eighth byte of the descriptor
> Set endpoint 0 maxpacket to the correct value
> Send full 18-byte GET-DEVICE-DESCRIPTOR request
>
> There are a couple of loops and retries in there that I've left out, and
> the entire sequence is repeated if it fails.
>
> The new scheme (the "Windows" scheme) is the one used by current Microsoft
> operating systems (and therefore supported by virtually every USB device,
> one would hope):
>
> Reset the device
> Set endpoint 0 maxpacket to {8, 64, 64} for {low, full, high}-speed
> Send 64-byte GET-DEVICE-DESCRIPTOR request. Since the
> descriptor is only 18 bytes long, this will terminate
> with a short packet. But if the maxpacket size is 8
> or 16 the device may be waiting to transmit some more.
> Reset the device again (clears out any data the device is waiting
> to send)
> Set endpoint 0 maxpacket to the correct value
> Send SET-ADDRESS
> Send full 18-byte GET-DEVICE-DESCRIPTOR request
>
> 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 am reasonably sure that the _proper_ way to do this is close to the
windows way with two resets, I have found a number of FTDI based
devices do not like a single reset either. (I can't rember where I
saw the double-reset, can't find it in the usb1.1 specification)
> 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?
>
> Alan Stern
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> [EMAIL PROTECTED]
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
