Date: Fri, 10 Sep 2004 09:44:22 -0700
>On Thu, 9 Sep 2004 [EMAIL PROTECTED] wrote:
>
>> Sorry, my explanations were not very clear:
>>
>> 1 - A first URB is submitted.
>> 2 - The device doesn't send any data
>> 3 - The first URB is unlinked and freed (timeout managment for example;
>> usb_bulk_msg() does this)
>> The completion handler is called, everything works well (I use
>> synchronous URB unlink).
>> 4 - A second URB is submitted
>> 5 - The device send data (with a mouse, for example, press one a button
and
>> don't release it).
>> Whith an USB analyser, I can see a packet but the IO completion
handler
>> (of the second URB) isn't called.
>> 6 - Then submit a third URB
>> 7 - The device send data and everything goes well (with a mouse, release
>> the mouse button)
>>
>> Strange isn't it ?
>
>Not necessarily. Maybe the packet you see in the analyzer represents only
>the beginning of the transfer, and the computer is waiting for more data
>before the transfer will be complete. What are the transfer_length of the
>second URB, the maxpacket value for the endpoint you're using, and the >size of the data packet from the device?
I agree, I known that an USB transaction terminates with a null packect or an incomplete packet (comparing the max packet size of a pipe) or when the amount of data transfered is a multiple of the maxpacketsize and equals to amount of data requested by the URB. So, when I reproduce the problem on a bulk pipe (of a specific device), the max packet size is 64 bytes, any URB request 64 bytes and the device sends 6 bytes. When I reproduce this problem with a mouse, on a interrupt pipe, maxpacketsize is 4 bytes, any URB request 4 bytes and the mouse sends 4 bytes. In both cases, when the usb_unlink_urb() isn't used, each URB terminates immediately after the device send 1 packet. However, after I unlink an URB, the device must send 2 packets to terminate the new URB that has been submited after the call of the usb_unlink_urb() function. Unfortunately, only the last packet is available in the data buffer provided to that URB.
Regards, Thierry
Hi,
That is one weird mouse. Are you sure its maxpacketsize is 4. I bet it is 8 and the HID record size is 4. That means that each transfer will be completed on each reception and there is no zero length record.
Also, the zero length record ending a transfer of even maxpacketsize*n is only a requirement for control transfers. A user level bulk or interrupt protocol can use any method for determining when a transfer is done, if the protocol knows exactly how many bytes are transfered.
Regards, Steve
_________________________________________________________________
On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
