On Wed, Aug 29, 2012 at 8:01 AM, Pete Batard <p...@akeo.ie> wrote: > On 2012.08.28 13:11, Xiaofan Chen wrote: >>> Right now, and just like your tests, I'm pretty much seeing a read >>> failure against any mass storage device I try, when using the libusbK >>> driver. >> >> Please refer to previous reply to that one. It seems to me libusbK >> is less forgiving about the bulk transfer size. >> >> Just wondering if you set some non-default pipe policy for >> libusbK in the libusbx codes, that might cause the issue >> as well. >> http://libusbk.sourceforge.net/UsbK3/group__usbk.html#ga10f9e367e4241c431edc2cecd1bb827e > > https://github.com/libusbx/libusbx/blob/master/libusb/os/windows_usb.c#L2629 > > I think the issue is the interpretation of ALLOW_PARTIAL_READS from > WinUSB and libusbK. If you can tolerate the atrocious new SF code > browser interface (and for even more fun, try to copy a line!), [2] and > the "if (!mRequestContext->Policies.AllowPartialReads)" section seems to > indicate that K will reject a read buffer that is smaller than > MaximumPacketSize, unless the ALLOW_PARTIAL_READS policy is set. But we > disable this policy by default in X, as per [2], hence the issue. > > I have of course now been able to confirm this, by commenting out the > disabling of ALLOW_PARTIAL_READS in libusbx, and verifying that it lets > K complete the mass storage test where it previously failed.
It is great that you found and confirmed the issue. I was thinking along this line but had a quick look into the codes but was not able to find this. BTW, you are right the SF Code Browser (or even the SVN) is not that good. You can use the libusbK Google code svn browser which is much better. Travis will use the Google Code svn for libusbK development and only pushes to SF at release time. http://code.google.com/p/usb-travis/source/browse/trunk/libusbK/src/sys/drv_xfer_bulk.c > Now, with regards to where in libusbx or libusbK lies the problem, in > xusb, we do call libusb_bulk_transfer() and tell it we expect 36 bytes, > which is what K also indicates we receive. And according to what the > MSDN has to say on ALLOW_PARTIAL_READS [3], "Disabling > ALLOW_PARTIAL_READS causes the read requests to fail whenever the device > returns more data (on bulk and interrupt IN endpoints) than the caller > requested". Thus, considering that 36 bytes is what K reports, and we're > therefore not getting more data than we expect, even with > ALLOW_PARTIAL_READS disabled, I think K should let the transfer go through. > > Especially I don't think the comparison between stageLength and > MaximumPacketSize, that K does to decide what it should do with the > ALLOW_PARTIAL_READS flag, is what ALLOW_PARTIAL_READS is really about. > > Still, if needed, I don't see a major problem enabling > ALLOW_PARTIAL_READS in 1.0.13 (thought we want to check why we decided > to disable it in the first place, as some people may rely on it), but if > Travis agrees that the current implementation of ALLOW_PARTIAL_READS > might be off in K, I'd prefer a fix in there. > I will check with Travis. But he is busy now with some other things so I do not expect a quick response from him right now. > > [1] > https://sourceforge.net/p/libusbk/code/268/tree/trunk/libusbK/src/sys/drv_xfer_bulk.c#l68 > [2] > https://github.com/libusbx/libusbx/blob/master/libusb/os/windows_usb.c#L2661 > [3] > http://msdn.microsoft.com/en-us/library/windows/hardware/ff540304%28v=vs.85%29.aspx -- 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
