>>> WinUsb_GetAssociatedInterface should be the magic you need. >> Thanks, I'll try that.
That was what I was missing! The call didn't appear any where in the Microsoft example. Thanks! > I'm also curious with the results you'll get from bypassing libusbx > altogether. I implemented my test with direct WinUSB calls, and the behavior is still present; so I guess it's a Windows USB stack issue? Finally having some code to work with, allowed me to experiment with the WinUSB API some more. I found what I though would be exactly what I needed in WinUsb_SetPipePolicy with SHORT_PACKET_TERMINATE. But when I set it to TRUE, it caused the transfer to hang. So I set PIPE_TRANSFER_TIMEOUT and the transaction dutifully timed out. The zero length packet never appeared on the bus. I don't know why it doesn't seem to be working. Any insights? > As you may expect, the fact that you seem to be seeing the same > behaviour with very different driver and library implementations (the > libusb-win32 and libusbx-Windows backend have almost no code in common) > makes me a bit suspicious about this being a libusbx/Windows issue. > Especially, there's no extra logic to try to merge transfers, and we > pass the data to WinUSB (or the other driver) as soon as we have it. Actually, I thought it was libusb that had the code in common, I guess I should have looked farther down rather than farther up. I guess this is no longer really a libusbx issue. ~QSE ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
