Hi,
Sorry for the late reply. I finally managed to test and reproduce the
issue, as well as figure out what you can do to avoid it (and no, using
Zadig is not an acceptable workaround - it completely defeats the
purpose of using WCID in the first place).
What you really want to do to keep using WCID and avoid the problem is
set DeviceInterfaceGUIDs (with an 's') as a REG_MULTI_SZ in the
Microsoft Extended Properties Feature Descriptor (the one with wIndex
5), in your WCID descritptors. If you do that, libusbx should be able to
work with the WCID WinUSB driver installed by Windows for the second
interface. Also, don't forget that, since you use a REG_MULTI_SZ, you'll
need a double NUL to terminate the GUID string.
Basically, you want your device to return something that looks like the
attached output, as produced by xusb.
NB1: this specific device already has an MTP record for interface 0,
which is why you get an extra MTP record besides the WinUSB one for the
Microsoft Compatible ID Feature Descriptor at wIndex 4.
NB2: I'm using a modified version of xusb to get the descriptor at
wIndex 5 since WinUSB has a restriction that forces the wIndex to the
interface number when issuing an interface request. I also set the
device firmware is also set to return the wIndex 5 descriptor when
issuing a Device request. It's a long, pure Microsoft annoyance story...
NB3: Yup, I am adding WCID support to Android, since it's using WinUSB
for debug. I'm hoping to push a patch upstream at some stage...
NB4: I also tested that should also be able to get away with using a
REG_SZ as long as you use DeviceInterfaceGUIDs with a s, but I guess if
you're using plural, it should technically be a MULTI_SZ.
As to where the issue stems from, it seems that, while Windows has logic
that will list DeviceInterfaceGUID (without 's') registry entries when
requesting the DeviceInterfaceGUIDs (which is what we do at [1]), that
logic seems to break down if the interfaces are not handled by the same
driver. In other words, during the enumeration where we ask Windows for
all the GUIDs we should parse using SetupDi, identify devices using
WinUSB that we should support, we fail to get the GUID if the device is
composite an has only a DeviceInterfaceGUID property on an interface
other than the first.
Now, if the GUID for that interface is provided under
"DeviceInterfaceGUIDs" with an 's', it is properly returned when we
query it.
In light of this, I guess we should probably update our enum code to
query both the DeviceInterfaceGUID and DeviceInterfaceGUIDs, but of
course that will mean adding logic to remove duplicate GUIDs. And while
we're at it, we probably want to treat what we get from the
DeviceInterfaceGUID query as a REG_MULTI_SZ, and consider that we may
get more than one GUID there, which we don't do right now.
If someone wants to take a stab at the windows_usb.c update, please go
for it, as I'm going to continue to treat this as lower priority (due to
time constraints). For now, I'm just going to modify the WCID wiki to
advise the use of DeviceInterfaceGUIDs instead of DeviceInterfaceGUID.
But I must say that allowing both "DeviceInterfaceGUID" and
"DeviceInterfaceGUIDs" to define essentially the same property was a
sure way to create problems such as this one appear. Had Microsoft stuck
with using a single property name for the list of GUIDs, we would
definitely have avoided all this mess (and for the record, we followed
official MS documentation for using either one of those in WCID and the
infs generated by Zadig)...
Regards,
/Pete
[1]
https://github.com/libusbx/libusbx/blob/master/libusb/os/windows_usb.c#L1484
D:\libusbx\Win32\Debug\examples>xusb 18d1:4ee2
Using libusbx v1.0.17.10842
Opening device 18D1:4EE2...
Reading device descriptor:
length: 18
device class: 0
S/N: 3
VID:PID: 18D1:4EE2
bcdDevice: 0228
iMan:iProd:iSer: 1:2:3
nb confs: 1
Reading BOS descriptor: no descriptor
Reading first configuration descriptor:
nb interfaces: 2
interface[0]: id = 0
interface[0].altsetting[0]: num endpoints = 3
Class.SubClass.Protocol: FF.FF.00
endpoint[0].address: 81
max packet size: 0200
polling interval: 00
endpoint[1].address: 01
max packet size: 0200
polling interval: 00
endpoint[2].address: 82
max packet size: 001C
polling interval: 06
interface[1]: id = 1
interface[1].altsetting[0]: num endpoints = 2
Class.SubClass.Protocol: FF.42.01
endpoint[0].address: 83
max packet size: 0200
polling interval: 00
endpoint[1].address: 02
max packet size: 0200
polling interval: 00
Claiming interface 0...
Failed.
Claiming interface 1...
Reading string descriptors:
String (0x01): "asus"
String (0x02): "Nexus 7"
String (0x03): "12345678"
String (0xEE): "MSFT100?"
Reading Extended Compat ID OS Feature Descriptor (wIndex = 0x0004):
00000000 40 00 00 00 00 01 04 00 02 00 00 00 00 00 00 00 @...............
00000010 00 01 4d 54 50 00 00 00 00 00 00 00 00 00 00 00 ..MTP...........
00000020 00 00 00 00 00 00 00 00 01 01 57 49 4e 55 53 42 ..........WINUSB
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Reading Extended Properties OS Feature Descriptor (wIndex = 0x0005):
00000000 92 00 00 00 00 01 05 00 01 00 88 00 00 00 07 00 ................
00000010 00 00 2a 00 44 00 65 00 76 00 69 00 63 00 65 00 ..*.D.e.v.i.c.e.
00000020 49 00 6e 00 74 00 65 00 72 00 66 00 61 00 63 00 I.n.t.e.r.f.a.c.
00000030 65 00 47 00 55 00 49 00 44 00 73 00 00 00 50 00 e.G.U.I.D.s...P.
00000040 00 00 7b 00 46 00 37 00 32 00 46 00 45 00 30 00 ..{.F.7.2.F.E.0.
00000050 44 00 34 00 2d 00 43 00 42 00 43 00 42 00 2d 00 D.4.-.C.B.C.B.-.
00000060 34 00 30 00 37 00 44 00 2d 00 38 00 38 00 31 00 4.0.7.D.-.8.8.1.
00000070 34 00 2d 00 39 00 45 00 44 00 36 00 37 00 33 00 4.-.9.E.D.6.7.3.
00000080 44 00 30 00 44 00 44 00 36 00 42 00 7d 00 00 00 D.0.D.D.6.B.}...
00000090 00 00 ..
Releasing interface 0...
Releasing interface 1...
Closing device...------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
