Hi Pete, >> Forgot to add that my idea/hope was that libusbx, when setting backend >> of a composite interface, could check if this is not by chance first >> interface of an IAD-collection and if so, assign the same backend to the >> other interfaces of the collection as well. But I don't know in the >> moment, if such approach wouldn't interfere with the general design of >> libusbx or with one of the libusbx-supported drivers. > > It's more a case of this is a problem that very few people are expected > to encounter without being able to use either the workaround of > replacing the composite parent driver or have their app figure out which > interfaces are accessible from libusb and which aren't, so we're not > going to invest much resources into solving it (too few developers, too > little time).
The composite parent workaround is good enough for me in the moment, it just might become limiting in the future, that's why I raised the question... > If it's of interest to you, eventually, we are planning to provide an > interface that will allow Windows users to gain access to Windows > specific data, such as the name of the driver being used to access a > device/interface and/or whether it is libusb compatible. The idea then > would be that you would use that information in your app to decide which > interfaces are accessible. The Windows specific info's would be surely useful for various purposes, is that already somewhere on the roadmap? However I'm not sure if I get right your notes about "checking which interfaces are accessible". Am I right that such info could be mainly used to fail gracefully, because it will not help me get the other interfaces of the association group accessible through libusbx if the driver is attached to MI_00 rather than to the composite parent? > Unless we get many requests to add logic to allow additional interface > access based on the driver, we'll leave libusb users add that logic in > their application instead. Again I'm not sure if I don't miss something - am I correct that even if the app can figure out (e.g. based on the provided driver info's) which interfaces are accessible, there's no way to "allow" the additional interfaces for libusbx from outside? I.e. when IAD is in use and driver attached to its first interface, libusbx will talk just to this first interface and with the others I'm on my own - correct? Because not considering IAD's contentents during the enumeration, the lib does not realize that the additional interfaces are actually handled by the same driver - and I'm not aware of any interface allowing the app to make the lib realize that. > As you will understand, adding complexity in > the library for uncommon situations that can be handled at the app level > is something we'd prefer to avoid. The reason is it introduces points of > failure that then need to be tested forever and, unlike other software, > automating the testing of a library that relies on the presence of > external hardware devices isn't a problem that has a quick and easy > solution. Sure, I fully understand your position. Should I, however, read this among lines that if I try to be brave one day in future, get deeper into the libusbx and suggest a patch along the lines mentioned in the previous e-mail (parsing IAD's, assigning same backend to all of the interfaces under given IAD), it would be probably anyway rejected? > Microsoft decided to present devices with multiple interfaces as > independent devices on Windows by default, so if your application > targets Windows, you're probably better off trying to work within this > restriction instead. There's only so much that libusb will try to > abstract when the OS isn't exactly cooperative. My application targets multiple OS's, but of course needs to take Windows specifics in account... Thanks for all your insights, Jan ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
