On Mon, Jun 20, 2011 at 11:26:12AM +0100, Toby Gray wrote: > >1) Your SetAltInterface() TODO message > > > So I think the most likely way that this could get broken is if RIM > release a device which has the vendor specific interface being something > other than interface number 1. I'll start a FreeBSD virtual machine > installing in the background and see if I can reproduce the need for > that if statement so that I can modify it to use the bAlternateSetting > value instead of bInterfaceNumber. > > The corresponding code in Probe::ProbeDevice where it decides on if > SetAltInterface is needed will also need updating, but that's equally > straightforward.
Sounds good to me. > >2) The libusb 1.0 context > > > >I see that libusb 1.0 uses a ctx (context) pointer for init. Is it safe > >to call > >init multiple times? If not, we should flag it somewhere, since Barry's > >Init() must be safe to call multiple times. > > Won't the check on the value of initialized in Barry::Init() prevent the > USB library from being initialised more than once? Oops, you're right. Thanks. > >Also, that static context pointer bothers me. I'm tempted to create a > >context for Barry as well. > > > >The idea of an Init class is tempting, since we could put the Uninit() > >calls in the destructor, but I've run into problems before with libraries > >being shared in applications, and destroying a library is something that > >should be done carefully and explicitly by the application. This is > >probably why libusb 1.0 added a context to their library init. It makes > >it much safer to have multiple libraries using libusb all at once, > >without conflicts in their uninit timing. > > Agreed. Another issue would be which Barry APIs would start needing to > have the Barry context passed into them. Probe could probably wrap the > Barry context up into the ProbeResult, so it'd hopefully be only a small > change to the API. > > Perhaps a start would be to have a USB context but just have it as a > static inside common.cc, that way it's at least in the same place as > most (all?) of the other global statics in Barry. What do you think? I want to get away from a static context if at all possible. I believe you're right that the change to the API would be minimal. Probe is where the context would be fed in. Any state that would need to live for as long as the underlying libusb could be placed into the context. > >3) The Probe results > However I see a couple of problems with that. Firstly it gives the false > impression that you can keep ProbeResults around after reprobing, which > won't work with libusb 0.1 due to probing calling usb_scan_busses() to > be called and therefore invalidating previous DeviceIDs. This impression already exists, unfortunately. The user can copy around ProbeResults that outlive Probe. > Secondly I've got a background task of trying to get Barry compiling and > running on Android tablet devices. The bit that I'm currently stuck on > with getting Barry to compile for Android is that there is no > <tr1/memory> support in Android, so the Router class fails to compile. Ouch. Is there a technical reason for this on Android? > What would you say to going the other way and making DeviceID a proper > class and then either using reference counting (which could be managed > by a custom copy constructor for ProbeResult) or just using a shared_ptr > to wrap the DeviceID object? I like that idea a lot. :-) Actually, you could have an impl pointer in the DeviceID class, probably even managed with shared_ptr<> internally, and the DeviceID object could then be treated like POD, and copied straight. If DeviceID was small enough, every function that required a DeviceID* could instead require a reference, or even a copy. - 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
