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." > 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." 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. We may be able to fare better with libusb0/libusbK, since the doc seems to say that client drivers can query the composite parent, but now we need to modify external drivers, and we still can't solve anything when WinUSB is in use. > BTW, libusbx Windows also does not support Multiple HID > top level collections (only the first top level collection will be > used). The situation is a bit similar here. Yeah, but I don't think Jan can use HID, and you can't really force install the HID driver anyway. I also think this the HID situation is a limitation from the OS too (i.e. nothing we can do about it). 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. > 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. 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. If you were hoping to get anything related to this implemented quickly, you're only going to be disappointed. On that topic, I'm gonna be away for a few days starting now, so please don't expect anything from me for a while. Regards, /Pete [1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff540054%28v=vs.85%29.aspx ------------------------------------------------------------------------------ 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
