From: Seagull <se...@ar...> - 2001-07-07 04:57:00
|
Greetings, I have finally figured out why I am getting timeouts when I call usb_bulk_read() under FreeBSD 4.3 when speaking with the Creative NJB. The problem is short read support, which is not provided in libusb, and the way the FreeBSD 4.3 handles short reads on either the ugen device, in the uhci device, or within the USB stack (it's not clear exactly which is the culprit). What's not clear is how to solve the problem. The problem is that the ioctl(2) for USB_SET_SHORT_XFER must be called on the bulk endpoint before _any_ communications are sent on the bulk or control pipes (that is, before any ioctl() calls for USB_DO_REQUEST, which is what usb_control_msg() invokes, or bulk reads/writes). If the USB_SET_SHORT_XFER ioctl() is not made prior to these data transfers, then read requests on the bulk pipe for less than the max packet size (a short read) will fail on a timeout. Where this really becomes a problem is in the way libusb opens the bulk pipes. Essentially, they are not opened until a bulk data transfer is requested. This makes it difficult to ensure that the bulk pipe is configured to allow short reads prior to any control messages. What I have done as a workaround is this: 1. Added the ioctl() call for USB_SET_SHORT_XFER in ensure_ep_open() 2. Immediately after opening the device, I make a call to usb_bulk_read, requesting 0 bytes of data. This forces the USB_SET_SHORT_XFER ioctl() without actually invoking a read() on the pipe If I do this, all my bulk communications function properly. If I don't, my very first bulk read call fails on a timeout. I don't know where the fault lies. Certainly, libusb has got to provide support for short reads (both on the bulk and control pipes). But whether this odd behavior is do to ugen.c (which I doubt), uhci.c or somewhere else, I don't know. Cheers, -+JLS -- \ carpe cavy! seagull @ aracnet.com \ http://www.aracnet.com/~seagull \ (seize the guinea pig!) |