On Fri, 2009-07-31 at 15:34 -0400, Alan Stern wrote: > Daniel and David: > > This kernel patch implements the plan we discussed for handling short > bulk transfers. It adds a new URB flag: USBDEVFS_URB_XFER_START. Alan, I tried this patch, modified libusb accordingly, and it works! My test is a particular camera that sends a short packet to indicate that the host is not keeping up. I need the remaining URBs in the frame to be canceled in order to keep in sync with the frame boundaries. With your patch and the libusb modifications, keeping sync seems to be completely reliable. With the old method of doing the URB cancelation in libusb, I would often lose sync. Some more thoughts below... > But for bulk-IN URBs that do have this flag bit set, any fault other > than an unlink will cause the kernel to immediately cancel all the > following URBs for the same endpoint and refuse to accept any new ones. > This state of affairs will persist until an URB that also has > USBDEVFS_URB_XFER_START is encountered, at which point the behavior > reverts to normal. Such an URB would of course mark the beginning of a > new transfer. > For backwards compatibility reasons, I am a little bit concerned about the change in semantics of USBDEVFS_URB_SHORT_NOT_OK. The old behavior would only cancel one URB (the short packet) automatically. The new behavior causes all packets to be canceled. Won't this cause unexpected behavior for apps that previously used USBDEVFS_URB_SHORT_NOT_OK? As a suggestion, maybe the meaning of USBDEVFS_URB_XFER_START could be exactly inverted and it could be renamed, perhaps to "USBDEVFS_URB_CANCEL_ON_ERROR"? The behavior would then be to cancel any URBs that immediately follow an URB with an error, but only up until an URB that has URB_CANCEL_ON_ERROR unset. Also, what do you suggest as the best way to test at runtime whether a particular kernel has this flag available? With firewire, we have an ioctl that gives you a version for the API at run-time to test against. I suppose I could just try to submit an URB with the new flag set and see if it fails. Thanks again for doing this work, David -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
