On Tue, Aug 13, 2013 at 4:36 PM, Jan Becvar <j...@groget.org> wrote:
> Hi everybody,
>
> I have a question about a possible problem of accessing composite
> devices using interface association from libusbx. Not sure, but the
> problem might be related to the maling list thread
> "libusb_claim_interface() error with usbK driver"
> (http://sourceforge.net/mailarchive/message.php?msg_id=30123276) started
> last year by Markus, who also complained that he's not able to claim
> other interfaces but the first one. The answer there was that it's
> misconception and each interface acts separately (needing separate
> driver). But I would like to highlight the use of interface association
> in this case. I found few other similar-sounding topics in the mailing
> list and bug tracker but none of them seemed to mention interface
> association directly.

Your issue is different. Tim's answer is perfectly fine for normal
USB composite device. I think I understand your issue
better now that I have found a similar USB IAD device to try out
myself.

>
> To summarize the problem, I have a composite device using three
> associated interfaces (described by an IAD descriptor). Windows by
> default assigns usbccgp.sys driver which in turn presents the interfaces
> as subdevices wanting own drivers. Because usbccgp.sys recognizes the
> interface association, it wants driver just for the first interface of
> the associated group ("MI_00"). After installing a driver (e.g. WinUSB,
> using Zadig) for that first interface, libusbx allows to claim this
> first interface but not the other two associated ones, similar as
> described by Markus.

Your issue is different. But yes you will only be able to claim the
first interface in this case.

> Some brief observation of libusbx internals shows me that during device
> discovery the library assigns USB_API_COMPOSITE API to the device's
> composite parent. It also assigns (set_composite_interface()) correct
> SubAPI to the first interface (e.g. SUB_API_WINUSB), but no SubAPI to
> the other two interfaces - because the system only uses one driver per
> interface association

Rather "interface collection". And IAD device can have multiple
interface collections.

> and the libusbx library makes no attempt to look
> at the IAD and interface association. As a result, these interfaces are
> recognized as using USB_API_UNSUPPORTED and attempts to claim such
> interfaces end with error LIBUSB_ERROR_NOT_SUPPORTED (-12) as described
> by Markus (the call is routed through composite_claim_interface() to the
> unsupported_claim_interface() for the two "associated" interfaces).

What if you only claim interface 0? Will you be able to communicate
with interface 1/2? Could you post the debug log?

> If I replace the system-default driver for the composite parent
> (usbccgp.sys) with WinUSB directly, I can access all the interfaces, but
> this workaround isn't a good solution in the long run for me, because
> other versions of the device might use also other separate (independent,
> different driver) interfaces besides the associated group or even
> multiple association groups.

I see.

> Now I'd like to ask if I'm doing something completely wrong,
> misunderstanding the library interface or if this is a possible problem
> that needs to be approached by the library (e.g. considering interface
> association in set_composite_interface() during device enumeration).
>
> Please let me know if further information is required, thanks, Jan

Now I see a potential problem. I am not so sure if this is a libusbx
problem or not, or rather a libwdi/Zadig problem. If Zadig can
separate each interface, then you do not have the issue.

-- 
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

Reply via email to