On Fri, Jun 03, 2011 at 03:00:51PM +0100, Toby Gray wrote: > Hi, > > I've finally managed to get around to adding support for libusb 1.0. > This is to fix an issue with raw channels loosing data when running > using libusb 0.1 due to bulk read timeouts and transferred data being > dropped.
First of all, thank you *very* much for this work. Sorry for the delay in getting to these. > The changes are on my github branch at > git://github.com/tobygray/barry.git and are as follows: > > 4bf09c6b1034b5a80567 > <https://github.com/tobygray/barry/commit/4bf09c6b1034b5a8056777723b67198c2dcd099e> > > - This is the main reorganisation of the code to support two different USB Ouch... gigantic patch. :-) I'll be splitting this one up, I suspect, unless you would rather. :-) > libraries. > 66929841996ac1985f34 > <https://github.com/tobygray/barry/commit/66929841996ac1985f349c9e716d187578edcc94> > > - This changes the debian packages to always use libusb 1.0 I did not include this patch yet. It might be the right move, but I want to do more testing before leaving 0.1 behind by default. > cba4e6a668702764f06b > <https://github.com/tobygray/barry/commit/cba4e6a668702764f06bef388ec364a5c36c9dda> > > - This forces the RPM packages to always use libusb 0.1, I don't know > enough about the different RPM based platforms to know if they all have > libusb 1.0 available, so this seemed the most sensible choice. This appeared to remove the libusb-devel dependency completely. That didn't seem right, so not including yet either. > d409f601e001556650ba > <https://github.com/tobygray/barry/commit/d409f601e001556650ba66159b108e4da8ee4295> > > - Is a minor change to allow the test script to run in dash if that's set > as the system shell Barry doesn't support dash. :-) Sorry. The right fix is to change the shebang, I think. I'm not willing to give up bashisms in my shell programming. None of Barry's scripts are speed-critical, so dash is not a requirement from that perspective. > Of these changes I think the only possibly controversial changes are: > * How I've done the private implementation for the various USB wrapping > classes. It just uses a private struct rather than the more tradition > private implementation pattern of deferring all API calls to a private > class. The only reason I did this was because I couldn't see any good > reason for writing out all the methods wrappers to the private > implementation method (e.g. Device::DoStuff() { m_impl->DoStuff() } ). > However I'm happy to add all these methods if it's preferred. I use the private struct myself. I don't mind. > * The change of breset and bcharge to using libbarry. There might be > reasons for these two tools using libusb directly which I'm not aware > of, so I made these changes as a separate commit. They weren't a separate commit that I saw. :-) I think they were included in the gigantic one. bcharge is meant to be standalone. It started out as C as well, but that didn't last. The idea was to enable USB charging with the minimal dependencies. Since USB charging has been removed from the kernel as well, Barry is the only software that supports this. If possible, I'd like to keep bcharge somewhat separate, because of this. > Any other comments or suggestions are welcome. I'm going through the changes in usbwrap.h, and I see you moved SetAltInterface() to Interface instead of Device. Not even libusb does this... it requires the device handle in SetAltInterface() and so to my mind, this is part of the Device class. I see that the Match class is a goner, as well as the container-like wrappers for device and endpoint discovery. I'm not sure how I feel about this. Would you care to share your reasoning for breaking that API so much? I didn't do the porting, so maybe it was a lot of work to try to maintain that API. But I'd like to know why it's gone. Thanks! - Chris ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
