Hello,
First thanks again for Alan Stern and David Bornwell.
Regarding the -75 error (-EOVERFLOW) : it could be that the
cause for the problem is in that the camera sends 196 bytes packet
and not 195 (But I do agree that setting it to 195 in the host controller
does not prove this beyond doubt; furthermore , it is clear to me that such a change is
not permitted ).
I will make a test on a 2.6 kernel ,but my target is 2.4.20 kernel,
so this test can only give a hint, but even if successfull it won't solve the problem.
However, I do have a problem now which I do not know how to solve:
I cannot use aletrnate setting 1 ; the usb_set_interface succeeds, but I have
the -OVERFLOW in the usb-ohci and as a result in the driver handle
(pwc_isoc_handler()).
Any ideas how I can solve this problem will be appreciated.
regards, John
From: Alan Stern <[EMAIL PROTECTED]>
To: John Que <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: [linux-usb-devel] actual_length of iso_frame_desc is 0 in handler after usb_
Date: Thu, 15 Jul 2004 14:17:31 -0400 (EDT)
On Thu, 15 Jul 2004, John Que wrote:
> Hello,
>
> Tnxs for Alan's detailed answer; it really shed light on the problem.
>
> After reading it , it came to my mind to perform another (last ?) test:
>
> I had noticed that when using default alternate setting of the driver ,
> when everything works OK and there is no usb error, the MXPs of the EndPoint
> is 292.
>
> However, the actual_length of the urb->iso_frame_desc[i].actual_length is
> 291 !
> (in the driver completion ,namely in pwc-if pwc_isoc_handler()).
>
> And as you would expect, the urb->iso_frame_desc[i].actual_length is also
> 291 in usb-ohci.c.
>
> It is one less the MxPs of the EndPoint.
There's nothing wrong with that. Devices are allowed to send packets shorter than the maxpacket size and shorter than the .length field.
> So I set the urb->iso_frame_desc[i].actual_length to 195 in the usb-ohci.c
> and used alternate setting 1 (where MxPs is 196) .
>
> No I do not have the -75 error (-EOVERFLOW).
Doing this is a bad mistake. You shouldn't be messing around with anything in the host controller driver.
> But now there is another probelm, so it seesm to me :
> It seems to me that in the pwc driver (so I understand from the source and
> the documenatation inside) it recognizes EOF in a manner which is good for
> ther default setting (it seems to me that
> in such a case a shorter packet arrives, and when identifying such shorter
> packet this is a sign of the
> EOF).And when using alternate setting 1 , with constantly setting the size
> to 195 ,
> we don;t receive a shorter packet.
That's one of the reasons it's a bad mistake.
> Now I try to delve in 2 usb issues:
> How can I recognize and EOF packet ? is it by testing it's first 8 bytes
> (should be equal to 0)
> and some value for the 9th byte ? (I saw it in some usb webcam driver code).
I don't know anything about webcams. For general USB devices, you can tell which packet marks the end of a message because its .actual_length is shorter than the maxpacket value. But I don't know if that's true so much for iso streams.
> The second is:
> how, when using default setting, the urb->iso_frame_desc[i].actual_length
> is set to one less than
> MxPs (namely , to 291 intead 292; 202 is the MxPs of the EndPoint).
It must be because the camera only sent 291 bytes in the packet, not 292.
Have you considered using Linux 2.6? You might find that it solves some of your problems.
Alan Stern
_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus
------------------------------------------------------- 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
