On Tue, Aug 13, 2013 at 6:15 PM, Jan Becvar <j...@groget.org> wrote: > On 13-Aug-13 11:36, Xiaofan Chen wrote: >> As replied by Tim in that thread, each interface of a USB composite >> device is a separated one. If you only installed the supported driver for >> the first interface, (Interface 0), then you can only claim interface 0 >> with libusbx, not the other two interfaces with unsupported driver. > > Thanks for the answer, although I'm still confused. Can you then give me > a hint, if there's a straightforward way how to install libusbx-friendly > driver to all the three interfaces covered by the IAD, e.g. using > Zadig/libwdi, while keeping usbccgp.sys for the composite parent?
Just install the WinUSB driver three times, one interface a time. >> If you replace the system composite parent by a supported driver, >> then of course you can claim all three interfaces since now they >> are all under the control of same driver. > > Or is the only way here to replace the system's composite parent driver? Not really, as mentioned above there is another way. > From my understanding of MS documentation related to IAD's handling, e.g. > http://msdn.microsoft.com/en-us/library/windows/hardware/ff537107%28v=vs.85%29.aspx > I believed that in presence of IAD the associated interfaces are really > always treated as belonging to the same driver (meaning if usbccgp.sys > is in control of the parent). What is your device? Could you post the descriptors? For example, if an IAD device has a custom interface and a CDC union (one data interface, one control interface), then Windows will treat it as two device, one custom device and one CDC device. In this case, if you want to use libusbx for all the three three interfaces, then you will need to install WinUSB for all three interfaces and it will become like three independent device > Brief comparison with libusb-win32 seems to indicate that this lib has > no problem with such setup (usbccgp.sys on parent, libusb0.sys on IF 0), > but of course there the enumeration process is completely different. Even in that case, you should still not be able to use libusb-win32 on Interface 1 and Interface 2. > Finally, during my earlier experiments, I tried a trivial > "hack"-modification of libusbx, assigning the same backend (subAPI) to > the associated interfaces as to the first one - and after this > modification everything "just worked", therefore I was hoping there > would be a solution. However, due to my lack of knowledge of libusbx > internals, I'm of course not sure if such approach might have some > unexpected side effects. What do you mean by "just worked"? What is your device and what is your goal of using libusbx? -- Xiaofan ------------------------------------------------------------------------------ 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