From: Travis <lib...@gm...> - 2010-10-04 13:32:32
|
On 10/3/2010 7:02 PM, Xiaofan Chen wrote: > On Mon, Oct 4, 2010 at 9:13 AM, Graeme Gill<gr...@ar...> wrote: >> One thing I noticed when adding libusb0.sys to libusb v1.0, is that >> the isochronous support is not quite the same. libusb v1.0 supports >> a packet size for each packet, whereas libusb0.sys assumes a constant >> packet size for a given transaction. Perhaps this is something that >> could be added to libusb0.sys ? Yes, it could. And I agree that this is something we should look at adding. I remember reading something about this in your 1.0-back-end code comments. ;) One problem here is that a 'libusb_iso_packet_descriptor' is a bit different than what windows will use. http://libusb.sourceforge.net/api-1.0/structlibusb__iso__packet__descriptor.html http://msdn.microsoft.com/en-us/library/ff539084%28VS.85%29.aspx However, we would still need to allocate USBD_ISO_PACKET_DESCRIPTOR structures in the driver. IE: The user mode iso packet descriptors would not necessarily have to be USBD_ISO_PACKET_DESCRIPTOR. There is room for improvement in libusb-win32 where iso transers are concerned. It also does not *really* support high speed ISO endpoints, although it will still work in many cases. >> (For backwards compatibility the >> best approach would be to add a new IOCT.) Yes, To do this correctly it would need to be a new IOCTL. The problem here is the iso packet descriptors need to be updated and passed back to the user. If it wasn't for this we could probably squeeze it under the same IOCTL. > I tend to think this is not so easy. It would take some work. Support for all of this would have to be added to the dll as well. > On the other hand, I do not > have a good understanding of the libusb-win32 isochronous > transfer functions myself even though I tried it before and > it seems to work fine. > libusb-win32 doesn't support all iso transfer scenarios. In-fact it really only supports a scenario where the the device is *full* speed and iso packet size is constant for all packets. Regards, Travis |