Re: [libusb] Correct use of libusb with composite device

[David G. <dav...@gm...>]

OK, if you just want to use WinUSB for the whole device, your descriptors
look OK to me, but I didn't check every byte.  They are very similar to the
working open source example here, except that you use DeviceInterfaceGUID
instead of DeviceInterfaceGUIDs:

https://github.com/pololu/libusbp/blob/9b97ca6/test/firmware/wixel/main.c#L429-L456

You might want to change your device's product ID or serial number to force
windows to reload the descriptors.

--David

On Sat, Jul 22, 2023 at 8:35 PM RisingEdgeIndustries <
su...@ri...> wrote:

> Hi David,
>
> Thank you for the help.  I actually went that route first, but libusb1.0
> doesn't support multiple interfaces with the usbccgp.sys driver.  I have to
> change to using WINUSB for the entire composite device.  So instead of
> windows using usbccgp.sys creating a separate device for each interface
> like it was doing, I need to assign WINUSB to my composite device so I get
> a single device with the WINUSB driver assigned.  Inside this are two
> interfaces that libusb1.0 could then get a hold of and utilize.
>
> Sorry about this confusion, the thread name reflects my original plan, but
> the libusb devs pointed out that I need to go the route of WINUSB being
> assigned to the composite device so it shows up as a single WINUSB device
> in device manager.  From there I can access the two different interfaces.
> So I"m working on implementing that, but I'm stuck trying to figure out now
> what is wrong with my MS OS 2.0 descriptors that should be associating the
> WINUSB driver with the composite device.
>
> I *think* the current descriptor setup I had in the last email reflects
> the descriptors in the red box overlayed on a figure from the MS OS 2.0
> spec.  Unfortunately with those descriptors I'm still seeing windows
> associate usbccgp.sys with my composite device instead of WINUSB.  I
> apologize this is kind of convoluted now.
>
>
>
>
>
> On Sat, Jul 22, 2023 at 11:49 AM David Grayson <dav...@gm...>
> wrote:
>
>> You said at the beginning of the thread you have a composite device and
>> you're trying to get WinUSB associated with one of the interfaces, so I
>> think you definitely need configuration subset and function subset headers
>> or whatever they are called.
>>
>> Have you been able to find an open source example for your use case to
>> refer to?  That is the most reliable way to get it working.
>>
>> --David Grayson
>>
>> On Sat, Jul 22, 2023, 6:32 AM RisingEdgeIndustries <
>> su...@ri...> wrote:
>>
>>> Hi David,
>>>
>>> Thank you for the reply!  This makes sense I just wasn't sure - I'm very
>>> new to the windows driver side of things so confirmation is very helpful.
>>>
>>> I think I'm pretty close to getting WINUSB associated with my composite
>>> device so libusb will connect, but it seems there is something still
>>> missing from my ms os 2.0 descriptor set.  I thought I could just do the
>>> BOS descriptor response and then the following for the device level MS OS
>>> 2.0 descriptor set - do you know if that is correct?  I'm referring to the
>>> image showing the red box.  Or do I need further descriptors like
>>> configuration/function?  The 2.0 spec seems to say you don't need a
>>> configuration subset header/function descriptors if you are only specifying
>>> device level (not function/interface level) capabilities.
>>>
>>> [image: image.png]
>>>
>>> The BOS descriptor response seems to work from what I see in the traffic
>>> during enumeration:
>>>
>>> const uint8_t platform_capability_descriptor[] = {
>>>     // BOS descriptor
>>>
>>>     0x05,               // Descriptor size (5 bytes)
>>>     0x0F,               // Descriptor type (BOS)
>>>     0x21, 0x00,     // Length of this + subordinate descriptors
>>>                            // (33 bytes)
>>>     0x01,              // Number of subordinate descriptors
>>>
>>>     // Microsoft OS 2.0 Platform Capability Descriptor
>>>
>>>     0x1C,           // Descriptor size (28 bytes)
>>>     0x10,           // Descriptor type (Device Capability)
>>>     0x05,           // Capability type (Platform)
>>>     0x00,           // Reserved
>>>
>>>     // MS OS 2.0 Platform Capability ID (D8DD60DF-4589-4CC7-9CD2-65 9D
>>> 9E 64 8A 9F)
>>>     0xDF, 0x60, 0xDD, 0xD8,
>>>     0x89, 0x45,
>>>     0xC7, 0x4C,
>>>     0x9C, 0xD2,
>>>     0x65, 0x9D, 0x9E, 0x64, 0x8A, 0x9F,
>>>
>>>
>>>     0x00, 0x00, 0x03, 0x06,     // Windows version (8.1) (0x06030000)
>>>     0x9E, 0x00,                        // Size, MS OS 2.0 descriptor set
>>> (30 bytes)
>>>     0x27,                                  // Vendor-assigned
>>> bMS_VendorCode
>>>     0x00                                   // Doesn’t support alternate
>>> enumeration
>>> };
>>>
>>> If I only need the descriptors shown in the red box it seems I still
>>> (even with the GUID - dummy GUID I just copied off a web page) have a bug
>>> in my MS OS 2.0 descriptor set below because usbccgp.sys still shows up for
>>> my composite device.
>>>
>>> // MS OS 2.0 Descriptor Set
>>> const uint8_t ms_os_20_desc_set[] = {
>>>     // Descriptor Set Header
>>>
>>>     0x0A, 0x00,                         // Descriptor size (10 bytes),
>>> hard setting
>>>     0x00, 0x00,                         //
>>> MS_OS_20_SET_HEADER_DESCRIPTOR -> 0 (hardcoded value)
>>>     0x00, 0x00, 0x03, 0x06,     // dwWindows Version
>>>                                                // 0x06030000 - Windows
>>> 8.1
>>>     0x9E, 0x00,                        // wTotalLength (entire desc. set
>>> size)
>>>
>>>     // Microsoft OS 2.0 Compatiblity ID Descriptor
>>>
>>>     0x14, 0x00,      // wLength, length of compat id desc, hardcoded 20
>>> bytes
>>>     0x03, 0x00,      // wDescriptorType, MS_OS_20_FEATURE_COMPATIBLE_ID
>>> = 0x03
>>>
>>>
>>>     // Feature Descriptor - MS OS 2.0 Compatible ID Descriptor
>>>
>>>     'W', 'I', 'N', 'U',              // (8 bytes) Compatibility ID
>>> "WINUSB\0\0"
>>>     'S', 'B', 0x00, 0x00,      //
>>>
>>>
>>>     0x00, 0x00, 0x00, 0x00,        // (8 bytes) Sub-Compatible ID
>>> (UNUSED)
>>>     0x00, 0x00, 0x00, 0x00,        //
>>>
>>>
>>>     // Registry property descriptor
>>>
>>>     0x80, 0x00,             // Descriptor size (130 bytes)
>>>     0x04, 0x00,             // Registry Property descriptor
>>>     0x01, 0x00,             // Strings are null-terminated Unicode
>>>     0x28, 0x00,             // Size of Property Name (40 bytes)
>>>
>>>     //Property Name ("DeviceInterfaceGUID")
>>>
>>>     0x44, 0x00, 0x65, 0x00, 0x76, 0x00, 0x69, 0x00, 0x63, 0x00, 0x65,
>>> 0x00,
>>>     0x49, 0x00, 0x6E, 0x00, 0x74, 0x00, 0x65, 0x00, 0x72, 0x00, 0x66,
>>> 0x00,
>>>     0x61, 0x00, 0x63, 0x00, 0x65, 0x00, 0x47, 0x00, 0x55, 0x00, 0x49,
>>> 0x00,
>>>     0x44, 0x00, 0x00, 0x00,
>>>
>>>     0x4E, 0x00,             // Size of Property Data (78 bytes)
>>>
>>>     // Vendor-defined Property Data:
>>> {ecceff35-146c-4ff3-acd9-8f992d09acdd}
>>>
>>>     0x7B, 0x00, 0x65, 0x00, 0x63, 0x00, 0x63, 0x00, 0x65, 0x00, 0x66,
>>> 0x00,
>>>     0x66, 0x00, 0x33, 0x00, 0x35, 0x00, 0x2D, 0x00, 0x31, 0x00, 0x34,
>>> 0x00,
>>>     0x36, 0x00, 0x33, 0x00, 0x2D, 0x00, 0x34, 0x00, 0x66, 0x00, 0x66,
>>> 0x00,
>>>     0x33, 0x00, 0x2D, 0x00, 0x61, 0x00, 0x63, 0x00, 0x64, 0x00, 0x39,
>>> 0x00,
>>>     0x2D, 0x00, 0x38, 0x00, 0x66, 0x00, 0x39, 0x00, 0x39, 0x00, 0x32,
>>> 0x00,
>>>     0x64, 0x00, 0x30, 0x00, 0x39, 0x00, 0x61, 0x00, 0x63, 0x00, 0x64,
>>> 0x00,
>>>     0x64, 0x00, 0x7D, 0x00, 0x00, 0x00
>>>
>>> };
>>>
>>>
>>> Should I be seeing that GUID in the registry location where the
>>> composite device shows up?  Registry location below:
>>>
>>>
>>> Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1CBF&PID_0007\12345678
>>>
>>> My VID/PID is [0x1CBF / 0x0007]
>>>
>>> I have a feeling I'm leaving something out in the descriptor set, but
>>> the spec isn't detailed enough for me to know what exactly.
>>>
>>> Any guidance is greatly appreciated!  Thank you again!
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Jul 22, 2023 at 1:53 AM David Grayson <dav...@gm...>
>>> wrote:
>>>
>>>> Unfortunately, the GUID is a fundamental requirement for WinUSB as far
>>>> as I can tell.  As a low level in libusb and similar libraries, the GUID is
>>>> part of the name of the file that you actually open to access the device.
>>>> You can easily generate your own with a utility like uuidgen.
>>>>
>>>> --David Grayson
>>>>
>>>> On Fri, Jul 21, 2023 at 6:56 PM RisingEdgeIndustries <
>>>> su...@ri...> wrote:
>>>>
>>>>> Do you have to pass a GUID value to get WINUSB to be associated with a
>>>>> composite device using MS OS 2.0 descriptors?  I thought this unique
>>>>> identifier was optional in case you wanted it in the registry to find your
>>>>> device?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 18, 2023 at 1:16 AM Tim Roberts <ti...@pr...> wrote:
>>>>>
>>>>>> On 7/17/23 7:01 PM, RisingEdgeIndustries wrote:
>>>>>>
>>>>>>
>>>>>> *Question 1:*
>>>>>> It seems the key to MS OS 2.0 Descriptors is to set the bcdUSB field
>>>>>> to USB version 2.1 with a hex value of 0x0210.  This is pretty
>>>>>> straightforward, but as I"m using a USB 2.0 full speed device right now I
>>>>>> want to make sure there isn't something I'm missing that would render this
>>>>>> MS OS 2.0 descriptor approach incompatible due to a USB 2.0 full speed
>>>>>> device setting its bcdUSB version to 2.1.  Is this bcdUSB field only to
>>>>>> tell windows which MS OS descriptor version is supported or does it play a
>>>>>> role in determining other operational metrics?  I'm a little unsure because
>>>>>> the field defines *"USB Specification number which the device
>>>>>> complies to"*.  This leads me to believe I can't just plug in 0x0210
>>>>>> to get MS OS 2.0 descriptors - there are other thing associated with using
>>>>>> this value over 0x0200 which I'm using now for MS OS v1.0 descriptors
>>>>>>
>>>>>> There should be no incompatible changes -- there almost never are
>>>>>> when the version changes.  Microsoft uses the BOS to find out whether the
>>>>>> OS 2.0 descriptors are present, and the BOS is only supported with USB 2.1.
>>>>>>
>>>>>>
>>>>>> *Question 2:*
>>>>>> I read that WINUSB (I guess this is more a WINUSB thing than
>>>>>> libusb1.0) doesn't support access from multiple applications.
>>>>>>
>>>>>> Yes, although that's not the only driver that has that limitation.
>>>>>> Sharing a USB device between multiple applications is very tricky.
>>>>>>
>>>>>>
>>>>>> My goal is to have a logically asynchronous feel to the HID interface
>>>>>> by allowing a thread to monitor it and when data is present grab it and
>>>>>> hand it off to the main application thread.
>>>>>>
>>>>>> That's fine; it's kind of how the USB HID drivers work.
>>>>>>
>>>>>>
>>>>>> The reason I ask Question #2 is because I tried this with libusb1.0
>>>>>> and didn't know how to handle the two interfaces.  If I"m correct in my
>>>>>> understanding that this approach will work, what is the correct way to get
>>>>>> a hold of these two interfaces in the same application?  Do I make two
>>>>>> device handles and have one device handle the HID interface and the other
>>>>>> device handle the bulk interface.
>>>>>>
>>>>>> Yep, that's how you do it.
>>>>>> --
>>>>>>
>>>>>> Tim Roberts, ti...@pr...
>>>>>> Providenza & Boekelheide, Inc.
>>>>>>
>>>>>> _______________________________________________
>>>>>> libusb-devel mailing list
>>>>>> lib...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>>>>>>
>>>>> _______________________________________________
>>>>> libusb-devel mailing list
>>>>> lib...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>>>>>
>>>>