On Mon, 9 Sep 2013, Xiaofan Chen wrote: > On Sat, Sep 7, 2013 at 11:36 PM, Alan Stern <st...@rowland.harvard.edu> wrote: > > Slightly off the original topic but perhaps still relevant... > > > > There are several Linux programs using libusb-0.1 that don't work with > > libusb-compat. The reason is that they perform some or all of their > > I/O using the usbfs API directly, relying on libusb merely for listing > > devices and opening the device files. In particular, they get the > > device's open file descriptor by abusing the interface and reading the > > value directly out of the private libusb usb_dev_handle structure. > > Just wondering if there are any important programs here. If there > are not many, why not suggest them to move to libusbx API.
I don't know. Perhaps not many, but this may include a large percentage of unmaintained programs. For the one noteworthy case I am aware of (the Data Center program from Total Phase), I suggested to the vendor that they migrate to libusb-1. Evidently this had not occurred to them; instead they have been recommending various work-arounds to their customers. > Just wondering how easy for these program to migrate to > mixed libusbx API and directly usbfs API. Or is it faster for > them to use libusbx API and get rid of the usbfs API? I don't know. On the other hand, does libusbx provide an API for getting the OS's file descriptor from the device handle? > I know one of them which is libftdi-0.x async I/O which use usbfs > directly for Linux. Later libftdi1 migrates to libusb-1.0 API and > the problem no longer exists. > > > If libusb-compat were changed so that the initial parts of the > > usb_dev_handle structure were the same as in libusb-0.1 -- including > > the underlying file descriptor -- these programs might suddenly start > > working. (Note that doing this would require adding a function to the > > libusb-1.0 API for retrieving the low-level file descriptor.) > > > > Anybody feel like implementing this? > > How feasible is this? I doubt it would be very difficult, particularly since the changes can be restricted to operating systems that supported libusb-0.1 originally. > I am not so sure if any one wants to further develop libusb-compat-0.1 > other than bug fixes. Travis has done some work on integrating > libusb-win32 async APIs into libusb-compat-0.1 but the work is > not published. This isn't terribly important. If nobody does the work, it may not matter much. I noticed because for some time, Fedora has not provided libusb-0.1 support -- just libusb-compat (although for some reason the package is named "libusb", which made the situation rather confusing). In the end I had to get hold of an old source package for genuine libusb-0.1 and build it for my current system. It would be nice to spare other people the need to resort to such measures. Alan Stern ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
