Pete Batard wrote: > > Hotplug isn't there yet, and Liam's problem is because the Windows > > backend doesn't currently implement what the libusb-1.0 API currently > > offers. Without hotplug. This is a bug in the Windows backend. > > Implementing this will require some form of hotplug handling in the > Windows backend similar to what we would do for global hotplug handling > (i.e. separate event thread and the whole shebang). There's no other > way around it.
What does GetLastError() return in the relevant cases after the WinUsb functions return FALSE? The documentation is sparse. In any case, if transfers have been submitted and are on the flying list, and if timeouts are working, then the transfers must at the very least time out, even if WinUSB makes it impossible to determine exactly why. > If you want to call it a bug, then call it a deliberate bug, It's a bug also if you implemented the behavior on purpose. It doesn't match the libusb API in any case. > because, with the API requirement to send a specific error code on > device removal, we just said "we'll do that once we have global hotplug". The topic is that transfers don't complete at all rather than the error code. I think it could be acceptable, though weak, for early code such as this to have transfers time out if the device went away. The situation however seems to be that they do not complete at all, which is nothing other than a bug if indeed the case. > 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.) > (whereas you could really have spent 30 seconds looking for libusb > error codes returned by the Windows backend and easily found out > the answer you were looking for), Static analysis is fine, but empirical testing is even better. > >>> 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. > >> > >> Liam, I'm afraid you'll find that many people on these lists don't > >> agree with these kind of subjective statements from Peter. > > > > I guess that Liam gets the point; we don't have much data, so we > > can't say that this is a known problem. > > No. The point you have been trying to make, is that the Windows > backend is subpar compared to the rest of libusb and also that > extremely few people use it. Don't make things up. 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. //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
