In addition, the patch requests a full maxpacket-sized buffer when retrieving the list of languages, to prevent the possibility of a babble error. This is in line with the policy recommended by Martin Diehl.
Did I mention the cases I've seen, where devices get confused if you _do_ issue reads of a full maxpacket length?
They basically seem to misbehave if the last IN transfer isn't short.
Yeah, I remember reading CATC traces from Windows that would always do a short read to get the length of the string, and then the whole string, just like Linux does. I'm really supprised that this doesn't also break on Windows.
Exactly what kind of device is this? Does this device pass the usb compliant tests found at usb.org?
This particular device: USB 1.0 speakers from Philips, vendor/product codes 0x0471/0x0104. Audio and HID.
Don't know if they pass the current set of USB-IF tests; I can't run those without paying $$taxes$$ to MSFT. But they're pretty old and I'd not be surprised to learn that the USB spec has been "clarified" since that silicon froze, ages ago.
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
