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