Hi,
I modified my device as you specified on the wiki and it now works as
expected. Thanks a lot!!!
Regards,
Ramon
On 9/29/2013 9:52 PM, Pete Batard wrote:
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
------------------------------------------------------------------------------
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
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
------------------------------------------------------------------------------
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
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
