On Wed, 21 Feb 2007, Guido Körber wrote: > But any device not following the specs will hit a wall with Windows > and MacOS as well.
Don't be so sure. In Pete's case, the misbehaving device was a Microsoft keyboard! What makes you think Windows always implements the spec exactly? (Hint -- it doesn't.) > I don't think it is a good approach to break the > well behaving devices to support the misbehaving ones. Handling multiple reports in a single packet won't break well-behaving devices. > Having seen my share of bad designs I would assume that there may be > such pieces of junk around. Though the spec is also clear about the > behaviour in such situations: If the buffer of the device is full it > just overwrites entries. Yep. Manufacturers who ignore one part of the spec often ignore other parts as well. > Still not a particularly sound approach. > > If the device is not able to follow the specs then let it fail. You > are not doing anyone a favour by allowing designs that are outside > the spec. All that will achieve is ruining the spec and eventually we > end up with trial and error instead of plug and play. This attitude is absolutely contrary to the point of view used throughout Linux. We go to extreme lengths to support devices even when they violate the specs (provided we can do so without jeopardizing support for well-behaved devices). Just look at all the quirk lists and device-specific config options sprinkled throughout the kernel. If we did what you suggest, a remarkably large percentage of USB mass storage devices would not be usable with Linux. The result would not be to preserve the spec -- it's already far too late for that -- but only to convince people that Linux isn't any good. Bear in mind also the marketing power of Microsoft. An official specification doesn't stand much chance against it. If Windows doesn't support the spec properly, or does support an alternate version of the spec, then that's what the hardware will follow. Manufacturers don't test their devices against a hypothetical specification; they test them by seeing if they work with Windows. > In case of the IO-Warrior we currently have the situation that no > reports are accepted simply because out maxPacketSize is 8 and our > ReportSize is 7. So obivously your approach of asking for the maximum > is not working at least in our case. It's not obvious to me. Suppose you submit an interrupt-IN request with transfer_length equal to 8 instead of 7. The device will send a 7-byte report, the driver will receive it and process it correctly, and everything will indeed work. Now suppose you submit an interrupt-IN request with transfer_length equal to 7 and the device decides to send an 8-byte packet whose first 7 bytes contain the report and whose eighth byte is garbage. Your driver will get a -EOVERFLOW error and will probably lose the data in the report. Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
