On Tue, Mar 15, 2011 at 05:28:39PM +0000, Toby Gray wrote: > I believe that I've tracked the issue down to a limitation of the libusb > 0.1 API. If the bulk read gets data just as it's about to timeout then > libusb 0.1 just drops that data and returns the timeout. There's nothing > libusb 0.1 can do as the function prototype is: > > int usb_bulk_read(usb_dev_handle *dev, int ep, char *bytes, int > size, int timeout);
Prototype or not, dropping data on the floor sounds like a bug to me. If there is no way to leave the data for the next read, then it should be returned, in my view. Have you given thought to fixing libusb 0.1? It would take a while for the fix to work its way through the distros, but it would then match the compatibility layer, and would fix this bug. Regardless of what we do with Barry, I think libusb 0.1 should be fixed, too. > Because of this I've been thinking of adding support for libusb 1.0 to > Barry. Are there any objections to adding support for libusb 1.0, > provided that libusb 0.1 is still supported? No objection at all. :-) > My thinking was to have the configure script preferring libusb 1.0 to > libusb 0.1, but falling back to using libusb 0.1 if libusb 1.0 isn't > available. I would imagine that most users of Barry are most interested > in syncing with the device, so the connections aren't open anywhere near > long enough to see this issue, so it would seem silly to force people to > have libusb 1.0. I agree with this plan. And if you do this, please add a configure option, so the user can choose at ./configure time which libusb to use, and then add a compile test to test/buildtest.sh. I run this script before releases, and periodically during development, and even though it takes a while to run, it does catch build system bugs that I would otherwise have missed. > I almost certainly won't have time to do this change immediately, but > before working on it in spare time I wanted to check with the Barry > community for any suggestions. Go for it! :-) When you have time. I'm aiming for an 0.18.0 release within a few weeks, so that people can test the new work-in-progress desktop GUI with binary packages. But there's no rush to get libusb 1.0 support in so quickly. I'd like to get back to more regular releases... maybe every 1.5 months or so. So libusb 1.0 support can go in 0.18.0 or 0.19.0 as time permits. - Chris ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
