Menu
▾
▴
Re: [libusb] Correct use of libusb with composite device
|
From: David G. <dav...@gm...> - 2023-07-22 16:49:30
|
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
>>>
>>
|
