On Mon, 4 Feb 2008, Alan Nisota wrote: > Alan Stern wrote: > > On Mon, 4 Feb 2008, Alan Nisota wrote: > > > >> I am trying to write a usb device driver for an R5000 modified > >> set-top-box. This just adds a USB interface to the decoded signal from > >> a satellite STB so you can save whatever is currently being watched on TV. > >> > >> I snooped the USB bus in Windows, and am able to upload the firmware and > >> communicate with the device just fine on endpoints 01 and 81. However, > >> retrieving the stream requires a high-bandwidth read on 82. If I do > >> this using blocking reads, the device never sends any data back It > >> appears to be waiting for multiple bulk request URBS in the queue. > > > > You have phrased this badly. This device can't be waiting for multiple > > URBs in the queue because it has no way to be aware of individual URBs. > > All it knows about are the packets it receives.
> Hmm, that is strange. I'm at a loss as to why it stalls without > returning any data then when I don't queue the packets. You queue URBs, not packets. And if you don't queue any URBs, how can you expect the device to return any data? > >> This > >> apparently eliminates my ability to use libusb, so now I need to do the > >> same thing in kernel-space. > > > > Not at all. Even though libusb may not currently support it, the > > underlying usbfs ioctl calls allow you to do asynchronous I/O from > > userspace. > But I need to do bulk transfers. UsbSnoop reports bulk requests, and the > endpoint type is bulk usbfs allows you to do asynchronous I/O with bulk transfers. > > Maybe the device really does try to send packets that are larger than > > the maximum allowed limit. That would explain your problems, > > especially if Windows doesn't bother to enforce the limit at all. > Is there any way for me to see what is actually being sent over the USB > bus (rather than what seems to be sent to the driver) in Windows? Not without special hardware. You can buy USB bus analyzers, but the ones that support monitoring high-speed transfers are pretty expensive (i.e., $10,000 and up). > It > seems that UsbSnoop is reporting what is sent to the driver since I > don't see data being packetized like I'd expect. That's right. > I'd think that if the > spec isn't followed that USB hubs wouldn't work with the device, and > they seem to work fine. Then again, I know little of USB, so I don't > really know what I'm doing here. Hubs wouldn't be much of a problem. They just send out whatever they receive. > I've tried virtual-box over linux, but I can't seem to get bulk requests > to work at all (even though the control requests work fine), (and no > other similar VMs support EHCI that I can find) so I'm not really sure > how I can proceed. I guess I can take a crack at analyzing the firmware > and see if it is obvious how the FX2 is configured. What does "lsusb -v" show for this device? And what do you see in /proc/bus/usb/devices? As far as I can tell, Linux doesn't try to prevent high-speed devices from using illegal maxpacket sizes. ehci-hcd should accept anything up to 2047 without complaint. Are you certain that your read length is a multiple of the maxpacket value? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
