So, in summary, the issue is: - you have developed a custom solution/layer to add hotplug to libusbx, even as libusbx is going to officially implement the very same feature, internally, in a manner that is likely to be quite different from yours. - when using this custom feature/layer, you are experiencing an issue, that may or may not manifest itself with the official libusbx hotplug implementation (hard to tell before we get there and time constraints make it difficult to try to find out in advance), but that cannot occur with the current non-hotplug usage of libusbx. - still, you would like libusbx to add a fix aimed at making your custom feature implementation work, regardless of whether this fix will be necessary when libusbx duplicates the same feature internally.
I'm afraid that, the way I see it, you are closer to using a derivative version of libusbx, that you would have modified to add your own feature (hotplug), than using a vanilla version. As such, any request pertaining to a custom addon would seem better left off the official tree, until we get to a stage where we have hotplug implemented, through the standard review process. Now, you may argue that your hotplug solution resides outside of libusbx itself, and therefore that you are technically using a vanilla version of the library which should "just" work with your layer. However, it's fairly obvious to me that any hotplug solution that isn't integrated into libusbx is likely to encounter issues, as it needs close ties to enum (which of course is difficult to do in a layer). And this is exactly what you encountered here, albeit only for Windows. Thus, unless our goal was to provide a modular version of libusbx, so that people can add their own custom layer to extend it, I don't think there is much point adding your fix to mainline ATM, as it is really only meant to address a behaviour that can currently only happen if people who use your custom layer, and therefore install an application for which you should be able to provide your own patches version of libusbx. As such, I would suggest that, until libusbx provides native hotplug, and you are able to replace your layer with the libusbx native feature, you maintain and distribute your own derivative version of the library, with any additional patches pertaining to your custom layer. I don't think it should be our job to add and maintain a fixes aimed at custom layers that replicate features that we very much have plans to implement. Otherwise, it would mean that, as soon as someone implements their own custom version of a feature in an extra layer, because we simply haven't had a chance to look into it (time constraints) or because they didn't want to participate in an officially endorsed effort, we will have to take time off actually implementing features, in order to review, implement and eventually remove patches aimed at supporting non-endorsed feature-duplicating layers... Regards, /Pete On 2012.05.13 11:42, Uri Lublin wrote: > On 05/04/2012 07:07 AM, Peter Stuge wrote: >> Hans de Goede wrote: >>> what is expected by spice is that after it detects a hotplug itself >>> (through platform dependent code) that it can then do a new >>> libusb_get_device_list() call and the new device will be there. >> What hotplug events are received? Ie. when a device driver changes, >> does the same device (as exposed by the Windows backend) go away and >> come back, or will the previous libusb_device actually have >> disappeared during the driver change? >> > > > We are listening, in the application level, for USB device added/removed > events. When a device-added event is received (*), > a libusb driver is installed for that specific device (assuming it was > not already installed). > When libusb driver installation operation successfully completes, libusb > can still not open nor use the device, as the backend api is > "Unsupported API". > With this patch, the application asks libusb to rescan the devices, > libusb updates the device backend api, and the application can access > the device via libusb, and continue with its usbredir operation. > > (*) Some conditions are to be met before that operation takes place, > such as the user requests this device to be shared with the guest. > > I hope that answers your question. > > Uri. > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
