OK, IMO, the best way to address that last issue we have with libusb0 as composite device is by modifying the libusb0 inf file to create a Device Interface GUID during installation.
In this case, this is really a one liner change in libwdi: --- "a/D:\\libwdi\\libwdi\\libusb0.inf.in" +++ "b/D:\\libwdi\\libwdi\\libusb0.inf.in" [libusb_add_reg_hw] HKR,,SurpriseRemovalOK,0x00010001,1 +HKR,,DeviceInterfaceGUIDs,0x00010000,%DeviceGUID% The problem is that, for composite devices, because the interfaces are not being enumerated during the pass when we have our first chance at picking up the driver name (only the parent composite device is then), we rely on the later passes, when we enumerate all the Device Interface GUIDs we picked up. Of course, that method falls flat for libusb0 at the moment, as it doesn't push any Device Interface GUID to the registry (unlike our WinUSB and libusbK driver packages). Now, there's probably a way to address this in the Windows backend (for instance by checking a *known* class GUID for libusb-win32. But if we require all libsub0 infs to use a unique class to work with libusbx, we might as well require them to set a random Device Interface GUID), so we might as well go with the inf requirement above. Thus I'd like to address this problem by: - Pushing the above fix into libwdi (I confirmed that it worked) and publishing a new version of Zadig that includes it within the next 24 hours. Since it's overdue, I'll also push a new release of libwdi, that can be used for the next libusb-win32 inf-wizard. - Keeping libusbx as is, with the 2 last fixes I have now pushed. Note that besides fixing the other composite issues, the last fix also changes the info message we previously discussed to debug. And the first fix targets xusb only (topology and speed info are now optional, with -i, and usage info saw a much needed update). The drawback of course is that, when 1.0.13 is release, people using inf-wizard or an older version of Zadig, or even their existing installation of libusb-win32, and wanting to use libusb0 for a composite interface (OpenOCD anyone?) will experience the issue... And now for some additional notes: Note 1: Unlike what is the case for the Class GUID, libwdi creates the Device Interface GUID on the fly (kind of makes sense if you want the interface GUID to be unique) Note 2: As long as you use the default composite parent Windows driver, you can very much access composite interface #2 with libusbx even if interface #1 has no driver, or a proprietary/non libusbx compatible one. It's only when WinUSB is in charge of the parent composite device that you have to claim #1 before you can claim #2. Note 3: Not having a Device Interface GUID is only an issue for composite devices. For anything that's not composite, it doesn't matter if the inf has one or not. I'll try to add a note about this in the Windows backend limitations. Regards, /Pete ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
