On Wed, 1 Sep 2004, David Brownell wrote: > > It's certainly not the kernel's fault. And the buffer size cannot be > > lowered back to 8, as raising it to 9 was necessary to work with other > > (slightly broken) devices. > > > > Another possibility is to increase the buffer to 64 bytes. > > Or to lower it to 4 bytes ... I was going to send in a patch that did that, > but the 9 byte patch went in first. The config descriptor's full size is > bytes index 2 and 3 in the buffer. > > A 4 byte request forces a short read in the same way 9 bytes does, > but 8 bytes does not. And a 9 byte request is prone to two different > families of boundary case bugs: 8 byte boundary for packet size, > and 10 byte boundary for the next descriptor in the group.
It's very unclear what the best course is. I've heard that some devices will crash if they are asked for less than the full device descriptor. I don't know how true that is, but I've seen at least one example of a device that crashed when asked for 8 bytes instead of 9. On the principle that vendors design their devices to work with Windows and test them that way, the best thing to do is to imitate Windows. Unfortunately, I don't know what Windows does when it encounters a low-speed or a high-speed device. Is there anyone out there with a bus analyzer who can try this and report the results? Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
