Hi, On 05/24/2013 06:07 PM, Nathan Hjelm wrote: > > On May 24, 2013, at 9:10 AM, Hans de Goede <hdego...@redhat.com> wrote: > >> Hi all, >> >> With some help from Pete, Xiaofan as well as Nathan, I have been working on >> integrating the libusb hp API work done by Nathan for 1.0.16 on top of >> libusbx. >> >> The plan is to release this as 1.2.0 within the next few weeks. >> >> On top of integrating Nathan's work I've now also added the wince fixes >> posted >> to the list a few days ago. >> >> Next on my hitlist was, and still is bos and ss-ep-comp support. While >> looking >> at this, I ended up taking a closer look at our config descriptor handling >> code, >> esp. the Linux bits, but also the generic parser parts. >> >> As a result of this I've done some significant cleanup / refactoring of the >> Linux >> config descriptor handling code, cleaning it up, fixing bugs, and fix the >> long standing issue of using usbfs descriptors on newer kernels where we >> really should not do that. >> >> I've also done some robustness fixes to the generic descriptor parsing code. >> >> Testing and review on all this new work is very much welcome. > > Will git pull and test my fixes on top of your current repository. > >> Last, but not least while doing my own testing I found an issue with the new >> hotplug code, where it breaks apps which are already doing hotplug on their >> own. For details and a fix see: >> https://github.com/jwrdegoede/libusbx/commit/9e40864617602eb37f6d8ad2e5acf67ba93634d8 > > Never considered that possibility. Shouldn't these apps move to using the > libusb > hotplug interface (not that I see any problem with the fix)?
Yes they should, eventually, but in the mean time we don't want to break them. >> I believe the new hotplug_poll function this introduces should be implemented >> under darwin too, as the same issue can likely happen there. > > Yup, there will probably be a race there but the fix may be a little more > complicated than > it is under Linux. So the question then maybe if there are any apps doing hotplug already (and thus on their own) for darwin, if there are no such apps, then we may consider simply not fixing this under darwin. Under Linux this is not really an option, since many libusb using apps simple hook into udev themselves to get hotplug support, and they expect libusb_get_device_list after a "add" action to contain the new device, and they tend to win the race with our own hotplug handler, since that does enumeration which is slow (and they just directly call libusb_get_device_list, expecting that to do the enumeration for them). Regards, Hans ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
