On Mon, Sep 3, 2012 at 10:51 AM, Alan Stern <st...@rowland.harvard.edu> wrote: > On Sun, 2 Sep 2012, Orin Eman wrote: > >> > it has a limitation on transfer size. Do you know what a typical value >> > for MAXIMUM_TRANSFER_SIZE is? >> > >> I don't, but comments on the OSR ntdev forum indicate in the order of MB >> for high speed devices, hundreds of KB for low and full speed devices and >> 4KB for control endpoints (any speed). >> >> Next time I'm working with our USB device, I'll put the relevant call in >> and find out. I use 32KB buffers, so the point is moot for me. > > Then it would be feasible for WinUSB backend to break a transfer down > to maximum-sized pieces and submit them one at a time. The overhead of > waiting for each piece to complete before submitting the next one > wouldn't be so bad. (A bounce buffer would be necessary for the last > packet if the transfer length wasn't a multiple of the maxpacket value; > that also wouldn't be so bad.) > > Then the RAW_IO flag could always be used and the other options would > be irrelevant. It's kind of a shame that Windows goes to such lengths > to provide the illusion of a continuous data stream instead of the > packetized stream that USB actually uses -- this just causes more > complications in the end.
Travis mentioned in the following thread that RAW_IO is recommended anyway for interrupt/bulk transfer (libusbK.sys isoc transfer only uses RAW_IO). http://libusb.6.n5.nabble.com/BSD-Wdf01000-sys-related-BlueScreen-tp5709840p5710133.html "There are some additional limitation when RAW_IO is enabled but for most it is a non-issue. RAW_IO will also significantly reduce overhead in the driver." I am not so sure what he means by "some additional limitation" though. -- Xiaofan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
