On Sun, 2 Sep 2012, Orin Eman wrote: > > Then as said that is a pretty useless feature, since apps can already > > find out as much by comparing the amount actually read versus the amount > > they requested... > > > > > Not quite. Without allow partial reads, if your buffer length isn't a > multiple of the maximum packet size for the endpoint and the device returns > more than your buffer length, you can lose data. With allow partial reads, > if less than your buffer length is returned by the device, the excess data > is buffered by WinUSB or discarded, depending on the AUTO_FLUSH setting. > > See: > http://msdn.microsoft.com/en-us/library/windows/hardware/ff728833%28v=vs.85%29.aspx
The description implies that ALLOW_PARTIAL_READS and AUTO_FLUSH are higher-level options meant to make life easier for driver authors. RAW_IO is closer to what libusb wants, but it's not an exact match: It requires the transfer size to be a multiple of the maxpacket value and it has a limitation on transfer size. Do you know what a typical value for MAXIMUM_TRANSFER_SIZE is? Interestingly, ALLOW_PARTIAL_READS has nothing to do with short packets, as Hans assumed. Instead, it means the WinUSB will allow the driver to read less data than the device sends, without generating a Babble error. Alan Stern ------------------------------------------------------------------------------ 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
