On 14-Aug-13 1:52, Pete Batard wrote: > On 2013.08.14 00:21, Xiaofan Chen wrote: >> The 2nd option is not possible without changes in libusbx. Right now >> it is not possible to access the other interfaces other than the first >> interface in an interface collection of a USB IAD device as of >> now, even though the supported driver (eg: WinUSB) is used to >> associate with the interface collection. > > I'm also worried about this part from [1]: > "Client drivers cannot access IAD descriptors directly."
This shouldn't be an issue, the IAD comes as a part of the data for the configuration descriptor request - the same page [1] says in the next sentence "IADs must be included in the configuration information that devices return when they receive a request from host software for the configuration descriptor (GetDescriptor Configuration)" which is actually true and I am reliably retrieving the IAD's through libusbx by parsing the libusb_config_descriptor::extra field - the library sees it, just considers it as unknown descriptor type. >> So it is an issue with libusbx for interface collection inside USB >> IAD device. Now that I realized that it is not possible to sort out >> the issue in libwdi/Zadig, then the only fix possible is to change >> libsubx to parse the IAD descriptors (interface collections). > > Which may or may not be possible, still as per [1]: > "Host software cannot retrieve IADs directly with a GetDescriptor request." Same as above should apply. > As far as WinUSB is concerned, I think the best we can get is > WinUsb_GetAssociatedInterface(), but that what we're already trying to > use. I saw this call in winusbx_claim_interface, but in my use case it's not excercised at all. For the first interface of the IAD collection it's not used, for the other ones the call falls through composite_claim_interface to unsupported_claim_interface, because the library does no assign the WinUSBx backend to those interfaces as described before. I would be curious to know, whether you see some principial issue with the suggested approach of simply assigning the same backend to all of the interfaces from the IAD, based on the knowledge that Windows always puts them under responsibility of the same driver. As mentioned before, in my tests that worked, but of course I need to admit that the tests included just limited set of operations interesting for my use case. > On 2013.08.13 20:48, Jan Becvar wrote: > > The Windows specific info's would be surely useful for various > > purposes, is that already somewhere on the roadmap? > > I don't think it is. That's partly because I personally have no idea in > which milestone we should add this (don't want to give users false hope > about getting it in version x.y.z) and also because that's not a feature > I'm likely to forget about. Understood, thanks. > > 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? > > I'm considering this from the perspective of: If you don't want to > replace the composite parent, you shouldn't be trying to consider these > interfaces as part of the same device, but as multiple independent > devices, and write your app from that perspective. Unless I'm missing something important here (and I feel Xiaofan confirms this view), there's no way around. Windows presents all the interfaces of the IAD collection as a single device (when using usbccgp.sys), I can attach just a single driver to it, see it as a single device through libusbx, but there's no way to access the other interfaces through libusbx in the moment. > In other words, you should try to forget about IADs for the time being > as Windows is not well suited to handle IAD in a generic fashion. No way for me, I need to live with the IAD based devices that are not under my control... > If you > were hoping to get anything related to this implemented quickly, you're > only going to be disappointed. Understood, thanks, for now the composite parent workaround needs to be the primary choice. Thanks again to all of you for all the advice. Regards, 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
