Hello David! > So, the INTR-OUT problem. For example, maxpacket size is 64, > period is maybe 8, but the driver needs to send 100 bytes. That > adds up to 64 bytes in one frame, then 36 bytes after a delay of > 8 frames ... then wanting to stop/unlink. This is one problem that > the LEGO folk have been seeing.
Another problem that bytes me: sending 16 Bytes all 2 ms, but have to adjust this size to 15 or 17 because of buffer handling in the device - synchronizing to the real world. > What if it does nothing, like today's drivers, expecting that to mean > the URB should continue being submitted? I did end up thinking > that completion callbacks needed to have a new capability, but > I didn't want to change the existing model (it doesn't bother me). > > My thought was pretty much to leave today's behavior alone, but > add a new usb_modify_urb() that's allowed to change the transfer > size for INTR-OUT urbs in their completion callbacks. Yes! Absolutely. This would fit it! > I certainly agree that unlinking the urb in the completion handler > should work portably; that's annoyance (b). That's an issue for > both IN and OUT interrupt transfers. For *each* sort of transfer, of course! And not only unlinking, but also freeing the urb! How long will it take to make the Linux USB api robust? > I guess I don't see why one-shot interrupt transfers would be > "the only thing that makes sense". They really seem like the > exceptional case to me. I'd rather design for the typical case > (a sequence of transfers) but allow them to stop in a cleaner > and quicker way than they can portably achieve today. Yes! best regards Wolfgang _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
