On 2013.04.08 19:12, Tim Roberts wrote:
> Xiaofan Chen wrote:
>> Somehow I got a strange warning under Windows 8 x64. The device
>> is a USB composite device (Amontec JTAGkey-2), both interface
>> use the WinUSB driver installed using Zadig. Not so sure if this
>> has something to do with the fact this is a virtual machine (using
>> VirtualBox under Mac OS X).
>
> I'm a little confused here. Do you have one driver matching the
> composite device, or do you have two drivers, one for each interface?
I guess that's 2 drivers, as one needs to use the advanced options of
Zadig to replace the driver for the usbcgpp device otherwise.
> For example, in this snippet:
>
>> Opening device 0403:CFF8...
>> libusbx: error [init_device] device
>> '\\.\USB#VID_0403&PID_CFF8&MI_01#6&222886B8&
>> 0&0001' is no longer connected!
>
> the "MI_01" implies that you have a separate driver for each interface.
> In that case, I don't understand the log entries about claiming
> interface 0 and interface 1.
That's just how xusb is set [1]. It'll always try to claim all
interfaces. I kind of recall there was a reason for doing just that
(couldn't get data off one of the devices I tested with otherwise), but
I'd have to look it up. Then again, xusb is only one side of the
equation here.
> When you have one driver per interface,
> the composite driver rewrites the descriptors so that each function
> driver sees a single interface device.
Yes, but the issue is that libusb was written with a Linux frameset in
mind, where composite devices are not seen as 2 independent entities but
as a single one. So we have to compensate for that in the Windows
backend, to provide for a cross platform implementation that does its
best at behaving the same across the board.
Otherwise, the expectation that when you open a libusb(x) composite
device, you are entitled exclusive access all its interfaces will not
hold true on Windows as it is for other platforms.
And that's the reason why, independently of xusb, the Windows backend
will also claim all interfaces of a composite device on open [2].
Sure would be nice if we could just address each interface
independently, but we're just constrained by how libusb(x) is meant to
work on other platforms.
With this being said, I ran a test on Windows 8 against an FTDI based
composite device (Olimex JTAG), and did not see the issue reported by
Xiaofan.
----------------------------------------------------------------------
D:\xusb>xusb 15ba:0004
Using libusbx v1.0.15.10641
Opening device 15BA:0004...
Reading device descriptor:
length: 18
device class: 0
S/N: 0
VID:PID: 15BA:0004
bcdDevice: 0500
iMan:iProd:iSer: 1:2:0
nb confs: 1
Reading configuration descriptors:
nb interfaces: 2
interface[0]: id = 0
interface[0].altsetting[0]: num endpoints = 2
Class.SubClass.Protocol: FF.FF.FF
endpoint[0].address: 81
max packet size: 0040
polling interval: 00
endpoint[1].address: 02
max packet size: 0040
polling interval: 00
interface[1]: id = 1
interface[1].altsetting[0]: num endpoints = 2
Class.SubClass.Protocol: FF.FF.FF
endpoint[0].address: 83
max packet size: 0040
polling interval: 00
endpoint[1].address: 04
max packet size: 0040
polling interval: 00
Claiming interface 0...
Claiming interface 1...
Reading string descriptors:
String (0x01): "Olimex"
String (0x02): "Olimex OpenOCD JTAG TINY"
Releasing interface 0...
Releasing interface 1...
Closing device...
----------------------------------------------------------------------
Hard to say what virtualization will do behind the scenes, so unless we
get similar reports on actual hardware, I'm not sure I want to
investigate that issue much.
Regards,
/Pete
[1] https://github.com/libusbx/libusbx/blob/master/examples/xusb.c#L830
[2]
https://github.com/libusbx/libusbx/blob/master/libusb/os/windows_usb.c#L4203
------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
