On 2012.05.14 20:21, Uri Lublin wrote: > (I also changed -k option's according to vid:pid of a usb disk I'm > testing with)
The fact that you tested with an usb disk may explain a few things. In that case, you're _replacing_ an existing driver (mass storage -> WinUSB) rather than installing a new one (no driver -> WinUSB). This seems to be confirmed as, after applying your patch to xusb, I still don't see an issue for a no driver -> WinUSB scenario, which is the one I had tested previously. Now, if I use a mass storage device (with the default mass storage driver installed, to be replaced by WinUSB) against your xusb, I can replicate your problem. However, your patch does the following: - list devices - identifies an "UNSUPPORTED" device and increases its refcount (meaning that the device instance remains even after free_device_list is called) - waits for the driver to be installed - tries to open the device, which fails for some specific original drivers (mass storage, possibly others) - decreases the refcount. Well, I would still deem this kind of usage as very unlikely for regular libusbx users. The part that I don't see is why you would want to keep a device, that you cannot access, refcounted? Obviously you won't be able to do anything with that device before the second call to libusb_get_device_list, and if not refcounted (i.e. destroyed after free_device_list), you should be able to just pick it up, as you did first time around, once the driver has been installed. Or does this mean that your app needs to keep all USB devices instantiated from the very first enum? The only way I could see this matter is if you want to duplicate a list of libusbx devices, that you'd populate on early on in your app, and then update as devices become accessible (either through a formal plug event or through a driver (re)installation)... but I'm afraid this still looks a lot like hotplug replication, and not something that I would expect regular libusbx users to do. I guess I'm still not clear as to why you must keep a device that libusbx reports as "UNSUPPORTED" instantiated, rather than let it be destroyed and pick up the new instance, with supported driver, on a subsequent get_device_list call... NB: For the sake of completion, also I did test a mass storage -> WinUSB driver installation in my previous test scenario (which doesn't keep refcounted instances between the 2 get_device_list calls), and it seems to work, though I also appear to be picking up secondary mass storage testing issues, unrelated to this whole problem (for instance I have a card reader that doesn't seem to return mass storage data, regardless of driver installation) Regards, /Pete ------------------------------------------------------------------------------ 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
