On Thursday 22 July 2004 08:15, Kyle Harris wrote: > I have a check scanner device (serial function): > > P: Vendor=1136 ProdID=3231 Rev= 1.00 > S: Manufacturer=CTS Electronics > S: Product=USB CTS LS100 > > If setup requests 8 bytes during the initial get_descriptor the device will > return 8 bytes, but then continously NAKs the following OUT transaction. > If I request 18 bytes initially, everything works fine. I have tested this > on 2 different linux platforms.
Periodically I think about changing how Linux does this -- to do exactly that: request 18 bytes of device descriptor right away to determine ep0 maxpacket, and assume it's 64 bytes at first (usually is!) rather than just 8 bytes. But I lack time to tweak such stuff. The downside of what Linux does today is exactly what Kyle noticed: certain hardware and/or firmware mislikes that initial short request, (in fact, misliking _all_ short requests seems to be the pattern) and things go haywire. On the other hand, changing it could just cause problems with _different_ hardware and that might not be a net win. Such a patch would IMO be a good experiment to try in the MM tree for a while. (Failures wouldn't be subtle ...) > Is anyone familar with this scenario? Any suggestions on how to > handle it? An initial get_descriptor of 18 bytes breaks other devices, > so that is not an option. What other devices does it break though? The only possible trouble would be hardware that doesn't respond correctly to the SETUP request that'd start the next request ... I don't happen to know about any such hardware, and that particular breakage would cause trouble in many other situations too. Fetching 18 bytes, with initial maxpacket guess of 64 bytes, should have three cases: - real maxpacket 64 -- nothing to change, no more fetches - real maxpacket 32 -- need to patch ep0 maxpacket, but also no more fetches needed - real maxpacket 16 or 8 -- patch ep0 maxpacket, then need to fetch the rest of the descriptor ... and relies on SETUP to work correctly (starting new control request) If there's hardware that misbehaves on that next SETUP, it's theoretically possible it'd also break on the RESET that'd follow such misbehavior. But that'd all be inside the hub_port_init() code, and I have a hard time thinking that anyone ought to care about hardware that's so deeply broken _both_ of those things will fail! - Dave ------------------------------------------------------- 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=4721&alloc_id=10040&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
