|
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!)
|