On May 24, 2013, at 10:37 AM, Hans de Goede <hdego...@redhat.com> wrote:
> 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). Yeah, the same should be true on darwin. I will keep an eye out for apps that implement their own darwin hotplug support. If I find any I will work on implementing the fix for darwin. In the meantime I will work on getting the internal device caching stuff ready. Shouldn't take much longer. BTW, libusb/os/poll_posix.c is missing from https://github.com/jwrdegoede/libusbx/commit/cc1472ab89374fb912b52434fe8cc1f1af7157c6 in your tree. -Nathan ------------------------------------------------------------------------------ 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
