Steve Hosgood wrote:
Meanwhile, I ran my driver with detailed debugging of its own and what I see is like this:
.... Receive 32768 bytes from camera: add it to the image-buffer Resubmit URB Receive 32768 bytes from camera: add it to the image-buffer Resubmit URB Receive 20667 bytes from camera: add it to the image-buffer (that marks the end of frame). This URB has been composed from 41 full 512 byte bulk-packets plus one half-filled 512 byte bulk-packet. Resubmit URB
[no more IRQs hit my callback function over the next tenth of a second]
What happens if the last URB submitted for the frame is only 20667 bytes, or whatever (frame_length % max_urb_size) is? I wonder if the firmware just isn't able to pad-out partial bulk packets reliably?
I think this is what the Windows driver does, more or less. I haven't done a trace in a while, but I think Windows has a function that basically just requests 'n' bytes from an endpoint and fills the whole image buffer all in one shot. In fact, I would bet that RawFrameLength from the .SET file is passed directly into that function.
-- Mark McClelland [EMAIL PROTECTED]
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
