Re: [Libusb-devel] proposed changes to core for Windows "poll" support

[Pete B. <pb...@gm...>]

On 2009.12.27 01:46, Tim Roberts wrote:
> How are you looking?  If the MI_## devices have an INF with a WinUSB device interface GUID, then they should all show up when enumerating through that device interface.

But the issue here is that we are at enumeration, hence we are seeking 
device properties that we don't know beforehand (including the Device 
Interface GUID). To be truly universal and user friendly, we cannot 
expect the device interface GUID to be provided by the user. If it is, 
then of course the issue is moot, but what of people who installed a 
WinUSB device outside of any libusb-winusb guidelines, and then threw 
away the .inf? (And yes, I know that if you look hard enough, you should 
be able to find a cached copy of that inf, but this kind of requirement 
is not exactly user friendly).

The way I am looking right now can be found around line 1013 at 
http://code.google.com/p/libusb-winusb-wip/source/browse/trunk/libusb/os/windows_usb.c
Basically, I've been trying to use the generic USB GUIDs defined at 
http://msdn.microsoft.com/en-us/library/bb663096.aspx, and especially 
the GUID_DEVINTERFACE_USB_DEVICE to enumerate all USB devices. 
Apparently the latter is not made to retrieve MI_## devices off the 
composite device however.

If I can get a device info list that contains the MI_## devices, then 
there shouldn't be any need for the controversial registry lookup.

> You mean the "device interface GUID", yes?
> I'm not exactly sure what you mean by "device GUIDs".  Devices do not, in general, have GUIDs.  With WinUSB, you create a "device interface GUID" to put into the INF file, and that's how you locate the device, using the SetupDi APIs.  A device interface GUID is quite different from a setup class GUID, and requires different parameters in the SetupDi search.  But if you have four interfaces with four different WinUSB GUIDs, you should be able to find them by using the GUIDs.

Yes I did mean "device interface GUID", and as I explained above, I am 
trying to avoid the requirement for libusb users of having to provide 
GUIDs. On other platforms, users can find all they need to know about 
their device through libusb enumeration, so why should Windows be any 
different? Or is there another way to list all the WinUSB device 
interface GUIDs? From what I gather, SetupDiBuildClassInfoList will only 
return the Class GUIDs, and there is no SetupDi equivalent function for 
Device Interface GUIDs...

> Well, the sentence is kind of backwards.  In order to use WinUSB, you have to have an INF for it that specifies the device interface GUID.  When WinUSB is loaded for the device, it registers the device interface GUID.  After that, you just use SetupDiEnumerateDeviceInterfaces to search for all of the devices that have exposed that device interface.

Which must be the reason why trying to use a generic USB GUID to list 
all the WinUSB device interfaces for a composite device fails.

> (...) but you are required to feel guilty when you rely on it.

I do, actually. Right now I'm checking if it's possible to use a more 
generic SetupDiGetClassDevs(NULL, "USB", NULL, DIGCF_ALLCLASSES | 
DIGCF_PRESENT) along with other SetupDi call to avoid the registry 
controversy and obtain the path for the MI_## devices...

> This was a change in philosophy.  Microsoft did not believe that it was useful or productive to worry about the specific path to a specific socket (and their reasons are defensible, because it leads one to think about the problem in the wrong ways).

But doesn't libusb use a similar kind of approach to access its devices 
(bus#, devaddr#), with the former being some kind of virtual hub, and 
the latter being construed as some kind of port # on this virtual hub?

> The "usbview" utility bypasses drivers altogether and sends ioctls directly to the USB hubs to build the tree.  However, it's not immediately clear how to get from that to a device handle.

I've been following the usbview approach to build the tree, and using 
the same ioctls actually. Usbview only sees the composite device however 
- not its interfaces...

Regards,

/Pete