Pete Batard wrote: > > What does GetLastError() return in the relevant cases after the > > WinUsb functions return FALSE? > > I'd expect "[22] The device does not recognize the command".
Do you know all possible reasons are for that error code? > > The topic is that transfers don't complete at all rather than the > > error code. > > The topic is that someone unplugs a device and expects some > specific unplug handling to occur, Think about it from the libusb API perspective rather than from the Windows API perspective; someone unplugs a device and expects libusb not to silently drop transfers. Even if Windows code doesn't yet support hot unplug, like the rest of libusb for a long time, at least transfers must not disappear. > Thus, unless there is an issue when the device remains plugged, I'm > not planning to do a thing about it That's up to you of course. Thanks for clarifying! > >> which is something you recently tried to get Uri to to test for you > > > > I asked Uri about what happens when drivers are replaced, which is > > distinct from physical unplugging, even if the same thing happens in > > both cases. (It makes sense for the same thing to happen.) > > I was referring to the following: > > On 2012.05.17 14:27, Peter Stuge wrote: > > If a device becomes unavailable (which can happen without this patch > > too of course) then the backend has to start failing transfers with > > LIBUSB_ERROR_NO_DEVICE. Is this what currently happens? Right, "device" refers to the logical device representation that libusb gets from Windows, not the physical thing. Of course I can work only on code without communicating at all, but for a new contributor I think pointers in interesting directions can be valuable for getting the problem solved, and they also help to show that there is interest in the problem. > Do I have to conclude that your earlier statements with regards to the > poor state of the Windows backend compared to the rest of libusb, on > linux-usb as well as OpenOCD were made up as well? Or do they bear no > relation whatsoever with what you have been trying to state here? You're really overreacting to me clarifying for a user that the observed behavior is a (deliberate) bug. > > What I did write, and you've quoted it several times now, is that > > there were few *reports*, which "doesn't mean much" because there > > can be many users who do not have the same trouble as Liam but have > > not let us know, because everything is working. > > Well, first of all, more than 2 years of mailing list archives do > dispute the "not very many reports of libusb use on Windows", > either for expected or problematic usage, Did you count? How many orders of magnitude off is ten-twenty then? Fifty reports would still be "not very many", at least compared to the hundreds of thousands SF number. > And you are also now somehow distorting "reports of libusb use" into > "reports of bug", which of course changes the meaning of the earlier > sentence altogether. Your sentence is confusing, but I think I understand it. "not very many reports of libusb use" does not refer to reports of bugs, but refers to reports of use, since I wrote "use." > Still, what would you say is the most logical interpretation of your: > "You are the first one to report it, but there have not been very many > reports of libusb use on Windows at all, so that doesn't mean much"? I actually think it is fairly clear as-is, but.. > 1. This is the first report we have for this issue, but not many people > *use* libusb on Windows, so there's a good chance it's a major issue in > the library. This is almost right, but you misinterpret the very part you emphasize. I wrote nothing about how many people use libusb on Windows. We can't know that. We can only know what we learn from actual feedback, and not many people have said that they use libusb on Windows. It could be hundreds of thousands, but it could also be ten-twenty. Maybe you'll agree that libusb and libusbx Windows support is still experimental though? //Peter ------------------------------------------------------------------------------ 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
