Am 20.02.2007 um 20:36 schrieb Alan Stern:

> On Tue, 20 Feb 2007, Pete Zaitcev wrote:
>
>> On Tue, 20 Feb 2007 11:57:14 -0500 (EST), Alan Stern  
>> <[EMAIL PROTECTED]> wrote:
>>> On Tue, 20 Feb 2007, Guido Körber wrote:
>>
>>>> There is no situation where a USB device sends multiple reports in
>>>> the same packet.
>>>
>>> I've never seen it happen myself, but Pete Zaitcev says he has:
>>>
>>> http://marc.theaimsgroup.com/?l=linux-usb- 
>>> devel&m=116545264427365&w=2
>>
>> That it true, I have seen it. However, it is not an argument for  
>> the use
>> of maxPacketSize to size URB-level transfers. In fact, I am yet to  
>> see
>> a good argument for it. In case of Microsoft Keyboard bubbling,  
>> for example,
>> there's no telling what the size should be... Maybe 6 bytes, maybe  
>> 20,
>> maybe 200. But whatever it is, it's not a maxPacketSize.
>
> Here's the argument for using the maxpacket size:
>
>       If we expect a single transfer to be larger than the maxpacket
>       size, then by all means, we should request the entire expected
>       amount.  (It might not hurt to round the amount up to a multiple
>       of the maxpacket size, but that's a separate matter...)
>
>       However, suppose the single transfer is expected to be smaller
>       than the maxpacket size.  In that case, requesting maxpacket
>       bytes
>
>           1.  Doesn't ruin anything, since we won't receive more than
>               one packet in any case;
>
>           2.  May prevent us from getting a -EOVERFLOW error and
>               losing data, should the device end up sending a
>               full-sized packet rather than what we expected.
>
> This argument applies particularly to interrupt-IN transfers, where we
> almost never expect to receive more than one packet per transfer.
> However it also can apply to short bulk-IN transfers.

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.

You need to use maxPacketSize as well as ReportSize. If the report is  
larger than what fits in a single transfer then you know what you  
have to do. But if you are looking for receiving a specific report  
there is nothing wrong with just asking for its size.

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.


--------------------------------------
Code Mercenaries
Hard- und Software GmbH
Karl-Marx-Str. 147a
12529 Schönefeld OT Grossziethen
Germany

Tel: x49-3379-2050920
Fax: x49-3379-2050930

HRB 16007 Potsdam
Geschäftsführer: Guido Körber, Christian Lucht

Did you subscribe to our Newsletter?
If not, do so immediately by sending mail to: [EMAIL PROTECTED]

Check out: www.codemercs.com



-------------------------------------------------------------------------
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

Reply via email to