Menu
▾
▴
Re: [libusb] Correct use of libusb with composite device
|
From: RisingEdgeIndustries <su...@ri...> - 2023-07-22 13:32:50
|
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
>>
>
|
