On Sat, 1 Aug 2009, David Moore wrote: > 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! Great! > 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? I doubt there are any such apps. USBDEVFS_URB_SHORT_NOT_OK was added in April last year, and there isn't any support for it in libusb. > 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. Or rather, up until an URB that has URB_SHORT_NOT_OK set and URB_CANCEL_ON_ERROR unset. Daniel, do you have any thoughts? I can change the code pretty easily. > 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. It's simple: uname(2). If the release value is >= 2.6.32 (or whenever this feature gets merged) then the new flag is available, otherwise it isn't. > I suppose I could just try to submit an URB with the new flag set and > see if it fails. That also works. :-) Alan Stern -- 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
