libusb-devel

Re: [libusb] Bulk Transfers Timeout on AMD EPYC Computers

[Xiaofan C. <xia...@gm...>]

On Wed, Jul 26, 2023 at 2:04 AM Chris Adams
<chr...@sr...> wrote:
>
> I messaged some time ago about an issue I was having with bulk end points
> timing out (https://sourceforge.net/p/libusb/mailman/message/37802472/) I have
> narrowed down the problem now and it is repeatable. For the test I use the Cypress
> FX3 SDK (which essentially just wraps libusb) and run their example code
> 09_cyusb_performance.cpp which uses the libusb asynchronous API to repeatedly
> read from a bulk endpoint (cypress fx3 development board).
>
> Steps to reproduce:
>
> Start 09_cyusb_performance
> In a separate terminal start stress-ng --hdd 2
> After a few successful transfers LIBUSB_TIMEOUT errors start
>
> The error occurs with the latest version of libusb 1.0.26 and older versions (1.0.24). The device
> can be recovered using libusb_device_reset but it happens again. I have tried long timeouts
> of 20s and it does not make a difference.
>
> I have tried this on 3 Intel machines with no issues. But it happens consistently on the two
> AMD EPYCs I have tried it on. The specs of the two machines I have tried it on:
> ...
> Where do I even start to solve this issue?

I will say to post the debug log first. Then try libusb git to see if
that makes any differences.

This may be a Linux kernel issue as well. So after you post the debug
log, you may also
want to check out linux-usb devel mailing list.


-- 
Xiaofan

[libusb] Bulk Transfers Timeout on AMD EPYC Computers

[Chris A. <chr...@sr...>]

I messaged some time ago about an issue I was having with bulk end points timing out (https://sourceforge.net/p/libusb/mailman/message/37802472/) I have narrowed down the problem now and it is repeatable. For the test I use the Cypress FX3 SDK (which essentially just wraps libusb) and run their example code 09_cyusb_performance.cpp which uses the libusb asynchronous API to repeatedly read from a bulk endpoint (cypress fx3 development board).

Steps to reproduce:

  1.  Start 09_cyusb_performance
  2.  In a separate terminal start stress-ng --hdd 2
  3.  After a few successful transfers LIBUSB_TIMEOUT errors start

The error occurs with the latest version of libusb 1.0.26 and older versions (1.0.24). The device can be recovered using libusb_device_reset but it happens again. I have tried long timeouts of 20s and it does not make a difference.

I have tried this on 3 Intel machines with no issues. But it happens consistently on the two AMD EPYCs I have tried it on. The specs of the two machines I have tried it on:

Failing Machine 1:
Model : H11SSL-i/C/NC
CPU: AMD EPYC Rome 16 Cores 7302P 3600MHz 110v MicrocodePatch Level: 8301034
RAM: 128GB DDR4 3200 Hynix 1.2V
GPU: Zotac GTX 1650 Super 4GB GDDR6
BIOS Version: 2.1
Build Date 02/21/2020
CLPD Version: 00.00.00
BIOS Type: AMI 128Mb SPI Flash EEPROM
USB Controller: TUSB7340 (https://www.ti.com/product/TUSB7340) (source: https://www.supermicro.com/manuals/motherboard/EPYC7000/MNL-2085.pdf#page=17 )
USB Module Version: 23
Product Page: https://www.newegg.ca/supermicro-mbd-h11ssl-i302p-ma015-o-single-amd-epyc-7000-series-processor/p/N82E16813183698?Item=N82E16813183698
Other Specs: https://www.supermicro.com/en/products/motherboard/H11SSL-i
Manual: https://www.supermicro.com/manuals/motherboard/EPYC7000/MNL-2085.pdf

Failing Machine 2:
Model: H12DSG-O-CPU
CPU: AMD EPYC 73F3 16 core Processor 3500MHz 1100mv Microcode Patch Level A001173
RAM: 256GB Micron DDR4
GPU: A400's 4x and the 1030gt
BIOS Version: 2.4
Build Date 04/22/2022
CPLD Version: F0.A4.4A
BIOS Type: AMI 256Mb SPI Flash EEPROM
USB Controller: ??? (https://www.supermicro.com/manuals/motherboard/EPYC7000/MNL-2299.pdf page 16)
USB Module Version: 27
Product Page: https://www.supermicro.com/en/products/motherboard/H12DSG-O-CPU
Manual: https://www.supermicro.com/manuals/motherboard/EPYC7000/MNL-2299.pdf

Where do I even start to solve this issue?

Chris
This e-mail is intended only for the named recipient(s) and may contain confidential, personal and/or health information (information which may be subject to legal restrictions on use, retention and/or disclosure).  No waiver of confidence is intended by virtue of communication via the internet.  Any review or distribution by anyone other than the person(s) for whom it was originally intended is strictly prohibited.  If you have received this e-mail in error, please contact the sender and destroy all copies.

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

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

The example file I linked to can be compiled two different ways: as a
composite device with WinUSB on one interface or a non-composite device
with WinUSB taking over the whole device.  There are different descriptors
for each case.  Both of them worked the last time I checked.  Maybe Windows
has cached some old descriptors for your device or you made an error.

--David Grayson

On Sun, Jul 23, 2023, 9:16 PM RisingEdgeIndustries <
su...@ri...> wrote:

> All,
>
> Thank you for the replies!  This is very helpful. I have already changed
> my code over to try to use the WINUSB only approach for the entire
> composite device.  Now that I'm stuck I'm hoping I can figure
> out/understand what I'm messing up as I'd like to continue to use MS OS 2.0
> descriptors to do more advanced stuff.
>
> I will be working this week on testing changes and reading more about your
> feedback here.  I think I have to be missing something obvious because I
> see the traffic and enumeration happens, but WINUSB never replaces
> usbccgp.sys.  It just enumerates with usbccgp.sys, then interface 0 is my
> HID interface which comes up fine then interface 1 (bulk) fails which makes
> sense because I'm no longer using the descriptors to associate WINUSB with
> interface 1 like I was before.  This is due to me attempting to change to
> WINUSB being assigned to the entire composite device.
>
> David - quick question about your example.  Even testing that example
> exactly with my composite device, it doesn't seem to work.  Would that mean
> there is a difference between how you apply that compatible ID descriptor
> to a composite vs non-composite device?  I assumed that structure would
> work for composite, but I'm wondering if you need a configuration
> descriptor etc...  Said differently, in the image I posted with the red
> box, you can't just use the descriptors in the red box?  you need more like
> the configuration subset header and the following information for that?
>
> Als, in Windows 10, is there a way to see the MS OS 2.0 descriptor
> information from the operating systems point of view during enumeration?
> Maybe I could see what windows is getting vs what I think it is getting
> from the device side?  I've tried to use event viewer but can't track down
> any MS OS 2.0 descriptor info.
>
> Thank you for your time!
>
>
>
> On Sun, Jul 23, 2023 at 3:18 AM Xiaofan Chen <xia...@gm...> wrote:
>
>> On Sun, Jul 23, 2023 at 11:38 AM 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.
>>
>> As mentioned before, this is incorrect and should not happen. libusb works
>> fine with multiple interfaces with the USB composite parent driver with a
>> few
>> exceptions. It should work with your case since you are not using USB IAD
>> and CDC-ACM.
>>
>> You should really post your libusb code and the debug log (with
>> LIBUSB_DEBUG=4).
>>
>> libusb git main will also work with USB devices with IAD
>> but still has some exceptions.
>>
>> Reference:
>> https://github.com/libusb/libusb/pull/965 (merged)
>> https://github.com/libusb/libusb/pull/1181 (not merged)
>> https://github.com/libusb/libusb/issues/1238 (no PR yet)
>>
>> --
>> Xiaofan
>>
>

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

[RisingEdgeIndustries <su...@ri...>]

All,

Thank you for the replies!  This is very helpful. I have already changed my
code over to try to use the WINUSB only approach for the entire composite
device.  Now that I'm stuck I'm hoping I can figure out/understand what I'm
messing up as I'd like to continue to use MS OS 2.0 descriptors to do more
advanced stuff.

I will be working this week on testing changes and reading more about your
feedback here.  I think I have to be missing something obvious because I
see the traffic and enumeration happens, but WINUSB never replaces
usbccgp.sys.  It just enumerates with usbccgp.sys, then interface 0 is my
HID interface which comes up fine then interface 1 (bulk) fails which makes
sense because I'm no longer using the descriptors to associate WINUSB with
interface 1 like I was before.  This is due to me attempting to change to
WINUSB being assigned to the entire composite device.

David - quick question about your example.  Even testing that example
exactly with my composite device, it doesn't seem to work.  Would that mean
there is a difference between how you apply that compatible ID descriptor
to a composite vs non-composite device?  I assumed that structure would
work for composite, but I'm wondering if you need a configuration
descriptor etc...  Said differently, in the image I posted with the red
box, you can't just use the descriptors in the red box?  you need more like
the configuration subset header and the following information for that?

Als, in Windows 10, is there a way to see the MS OS 2.0 descriptor
information from the operating systems point of view during enumeration?
Maybe I could see what windows is getting vs what I think it is getting
from the device side?  I've tried to use event viewer but can't track down
any MS OS 2.0 descriptor info.

Thank you for your time!



On Sun, Jul 23, 2023 at 3:18 AM Xiaofan Chen <xia...@gm...> wrote:

> On Sun, Jul 23, 2023 at 11:38 AM 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.
>
> As mentioned before, this is incorrect and should not happen. libusb works
> fine with multiple interfaces with the USB composite parent driver with a
> few
> exceptions. It should work with your case since you are not using USB IAD
> and CDC-ACM.
>
> You should really post your libusb code and the debug log (with
> LIBUSB_DEBUG=4).
>
> libusb git main will also work with USB devices with IAD
> but still has some exceptions.
>
> Reference:
> https://github.com/libusb/libusb/pull/965 (merged)
> https://github.com/libusb/libusb/pull/1181 (not merged)
> https://github.com/libusb/libusb/issues/1238 (no PR yet)
>
> --
> Xiaofan
>

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

[Xiaofan C. <xia...@gm...>]

On Sun, Jul 23, 2023 at 11:38 AM 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.

As mentioned before, this is incorrect and should not happen. libusb works
fine with multiple interfaces with the USB composite parent driver with a few
exceptions. It should work with your case since you are not using USB IAD
and CDC-ACM.

You should really post your libusb code and the debug log (with
LIBUSB_DEBUG=4).

libusb git main will also work with USB devices with IAD
but still has some exceptions.

Reference:
https://github.com/libusb/libusb/pull/965 (merged)
https://github.com/libusb/libusb/pull/1181 (not merged)
https://github.com/libusb/libusb/issues/1238 (no PR yet)

--
Xiaofan

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

[Maciej N. <mac...@gm...>]

It is possible to use a composite device with two separate WinUSB
"subdevices" with libusb and leave the parent device to be handled by
usbccgp.sys.

Take look at following gist:
https://gist.github.com/Novakov/3daed356fb9668e75855578450898a6b Code will
most probably not match your code/situation 1:1 but should be enough to
give you an idea what descriptors are required.

usb_descriptor.py - basic USB descriptor, showing composite device with 5
interfaces composed into three devices (1 interface, 3 interfaces grouped
together with IAD and 1 interface)
msft_descriptor.py - defines Microsoft OS Descriptors for entire device
(compatibility_id) and for each subdevice (extended_descriptor1..3).
CompatibilityId specifies which driver shall be associated with each
interface (note three sections and associated interface numbers).
ExtendedId for each subdevice sets DeviceInterfaceGUID property.
vendor transfer callback.cpp - implements vendor control transfers
(implemented with TinyUSB in this case). CompatibilityId descriptor is
returned for request 0x33 and index 4 - that tells Windows to associate
WinUSB drivers with subdevices. Request 0x33, index 5 is used to respond
with per-subdevice ExtendedId based on requested interface number (lower
byte of wValue).

With that setup Windows will use usbccgp.sys driver for root device and
expose three separate USB devices for each of the function/subdevice in
descriptors. If you would use WinUSB API directly it will be very visible
that they are treated as totally different devices (different file paths).
Libusb hides that separation by grouping all devices into a single handle,
however if you would deep dive into winusb backend implementation, an array
of 3 devices could be seen. With such a handle you can claim and perform
transfer to any of the interfaces. Note that you need libusb version with
https://github.com/libusb/libusb/pull/965 included.

Additionally if you would like to use subdevices from different processes
at the same time you will hit this bug:
https://github.com/libusb/libusb/issues/1177 fixed by not-merged
https://github.com/libusb/libusb/pull/1181.

Windows caches USB device information pretty aggressively so it's good idea
to increase bcdNumber on each change.

I hope that these information will help with your WinUSB + libusb project :)

Regards,
Maciej

niedz., 23 lip 2023 o 09:49 David Grayson <dav...@gm...>
napisał(a):

> 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
>>>>>>
>>>>> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

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
>>>>>
>>>>

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

[RisingEdgeIndustries <su...@ri...>]

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
>>>>
>>>

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

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

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
>>>
>>

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

[RisingEdgeIndustries <su...@ri...>]

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
>>
>

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

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

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
>

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

[RisingEdgeIndustries <su...@ri...>]

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
>

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

[Tim R. <ti...@pr...>]

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.

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

[RisingEdgeIndustries <su...@ri...>]

I think I understand the proper approach for libusb1.0 per my INF free
requirement fairly well now.  I also think I understand the MS OS v2.0
descriptors Xiaofan recommended as they will let me assign WINUSB  for the
overall composite device.  Now that I'm grasping this I'd like to
ask/verify two things if possible.

*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

*Question 2:*
I read that WINUSB (I guess this is more a WINUSB thing than libusb1.0)
doesn't support access from multiple applications.  This is fine, as I"m
planning on creating a thread to monitor traffic coming into the host HID
interfaces and using the main application thread to handle the bulk
interface.  Am I correct in assuming this is fine?  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.  The bulk interface will be controlled by the main
application thread directly by the user.  For example, Send 1k of data,
read 1k of data etc....  So one application with two threads.

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.  I'm assuming I have to use the claim
interface API call shown below:

[image: image.png]

I am hoping the expectation isn't to swap between interfaces by claiming
one then the other and going back and forth, but instead have two handles
and be able to utilise them in different parts of the application.
Basically trying to understand the correct software approach to take.

Thank you!




On Wed, Jul 12, 2023 at 9:24 PM Xiaofan Chen <xia...@gm...> wrote:

> In this case, you may want to use libusb xusb example and then post
> the full debug output
> of `xusb -d 1cbf:0007". Make sure you use the latest 1.0.26 release or
> git master.
>
> Best regards,
> Xiaofan
>
> On Thu, Jul 13, 2023 at 10:03 AM RisingEdgeIndustries
> <su...@ri...> wrote:
> >
> > So I'm taking the same approach I take when I had these interfaces
> running as stand alone devices.  My process is below.
> >
> >
> > Call get_device_list()
> > Loop through device list to find VID/PID
> > Once found open_device() with my VID/PID
> > [at this point I get string descriptors and max_packet_size() which
> works fin]
> > I then execute claim_interface() for my device
> >
> > I can claim interface 0, but when I try interface 1 I get the following
> error:
> > ERROR: failed to claim interface, ret val = -12
> > ERROR: code - b'Operation not supported or unimplemented on this
> platform'
> >
> > I know from the descriptors during enumeration my second interface is my
> bulk interface with bInterfaceNumber "1".
> >
> > I see both interfaces with correct VID/PID in device manager with
> correct drivers and no icons indicating a problem.  Is there something
> obvious I'm missing in this process?  This process works fine for
> non-composite HID only or bulk only.
> >
> >
> > Descriptor data:
> >
> >
> > ----- Device Descriptor -----
> > 12 bLength
> > 01 bDesc Type
> > 00 02 bcdUSB (LSB, MSB)
> > 00 bDeviceClass
> > 00 bDeviceSubClass
> > 00 bDeviceProtocol
> > 40 bMaxPacketSize0 - Maximum packet size for Endpoint zero (only 8, 16,
> 32, or 64 are valid).
> > BF 1C idVendor (LSB, MSB)
> > 07 00 idProduct (LSB, MSB)
> > 00 01 bcdDevice (BCD) (LSB, MSB)
> > 01 iManufacturer (string index)
> > 02 iProduct (string index)
> > 03 iSerialNumber (string index)
> > 01 bNumConfigurations (string index)
> >
> > ----- Configuration Descriptor -----
> > 09 bLength
> > 02 bDesc Type
> > 40 00 wTotalLen  (LSB, MSB)
> > 02 bNumInterfaces
> > 01 bConfigurationValue
> > 00 iConfiguration
> > 80 bmAttributes
> > 7D bmAttributes
> >
> > ----- Interface Descriptor -----
> > 09 bLength
> > 04 bDesc Type
> > 00 bInterfaceNumber
> > 00 bAlternateSetting
> > 02 bNumEndpoints
> > 03 bInterfaceClass
> > 00 bInterfaceClass
> > 00 bInterfaceProtocol
> > 00 iInterface
> >
> > ----- HID Class Descriptor -----
> > 09 bLength
> > 21 bDesc Type
> > 00 02 bcdHID (Hid Spec Release Number) (LSB, MSB)
> > 00 bCountryCode (Country code (0x00 for not supported))
> > 01 bNumDescriptors (Number of class descriptors)
> > 22 bDescriptorType (Report descriptor type)
> > 20 00 bDescriptorLength (Report descriptor type) (LSB, MSB)
> >
> > ----- Endpoint Descriptor -----
> > 07 bLength
> > 05 bDesc Type
> > 81 bEndpointAddress
> > 03 bmAttributes
> > 40 00 wMaxPacketSize (LSB, MSB)
> > 01 bInterval
> >
> > ----- Endpoint Descriptor -----
> > 07 bLength
> > 05 bDesc Type
> > 01 bEndpointAddress
> > 03 bmAttributes
> > 40 00 wMaxPacketSize (LSB, MSB)
> > 01 bInterval
> >
> > ----- Interface Descriptor -----
> > 09 bLength
> > 04 bDesc Type
> > 01 bInterfaceNumber
> > 00 bAlternateSetting
> > 02 bNumEndpoints
> > FF bInterfaceClass
> > 00 bInterfaceClass
> > 00 bInterfaceProtocol
> > 00 iInterface
> >
> > ----- Endpoint Descriptor -----
> > 07 bLength
> > 05 bDesc Type
> > 82 bEndpointAddress
> > 02 bmAttributes
> > 40 00 wMaxPacketSize (LSB, MSB)
> > 00 bInterval
> >
> > ----- Endpoint Descriptor -----
> > 07 bLength
> > 05 bDesc Type
> > 02 bEndpointAddress
> > 02 bmAttributes
> > 40 00 wMaxPacketSize (LSB, MSB)
> > 00 bInterval
> >
> >
> >
> >
> > On Wed, Jul 12, 2023 at 8:35 PM Xiaofan Chen <xia...@gm...> wrote:
> >>
> >> There is no limitation for your use case. Open the device normally and
> claim the
> >> correct interface (interface 1 in your case).
> >>
> >>  libusb_detach_kernel_driver() is not supported under Windows so it is
> >> not relevant.
> >>
> >> The limitations are mainly with things like IAD and CDC-ACM, not your
> use case.
> >> 1) https://github.com/libusb/libusb/pull/965 (PR merged, it will be in
> >> future 1.0.27 release)
> >> 2) https://github.com/libusb/libusb/issues/1238
> >>
> >> Best regards,
> >> Xiaofan
> >>
>
>
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

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

[Xiaofan C. <xia...@gm...>]

In this case, you may want to use libusb xusb example and then post
the full debug output
of `xusb -d 1cbf:0007". Make sure you use the latest 1.0.26 release or
git master.

Best regards,
Xiaofan

On Thu, Jul 13, 2023 at 10:03 AM RisingEdgeIndustries
<su...@ri...> wrote:
>
> So I'm taking the same approach I take when I had these interfaces running as stand alone devices.  My process is below.
>
>
> Call get_device_list()
> Loop through device list to find VID/PID
> Once found open_device() with my VID/PID
> [at this point I get string descriptors and max_packet_size() which works fin]
> I then execute claim_interface() for my device
>
> I can claim interface 0, but when I try interface 1 I get the following error:
> ERROR: failed to claim interface, ret val = -12
> ERROR: code - b'Operation not supported or unimplemented on this platform'
>
> I know from the descriptors during enumeration my second interface is my bulk interface with bInterfaceNumber "1".
>
> I see both interfaces with correct VID/PID in device manager with correct drivers and no icons indicating a problem.  Is there something obvious I'm missing in this process?  This process works fine for non-composite HID only or bulk only.
>
>
> Descriptor data:
>
>
> ----- Device Descriptor -----
> 12 bLength
> 01 bDesc Type
> 00 02 bcdUSB (LSB, MSB)
> 00 bDeviceClass
> 00 bDeviceSubClass
> 00 bDeviceProtocol
> 40 bMaxPacketSize0 - Maximum packet size for Endpoint zero (only 8, 16, 32, or 64 are valid).
> BF 1C idVendor (LSB, MSB)
> 07 00 idProduct (LSB, MSB)
> 00 01 bcdDevice (BCD) (LSB, MSB)
> 01 iManufacturer (string index)
> 02 iProduct (string index)
> 03 iSerialNumber (string index)
> 01 bNumConfigurations (string index)
>
> ----- Configuration Descriptor -----
> 09 bLength
> 02 bDesc Type
> 40 00 wTotalLen  (LSB, MSB)
> 02 bNumInterfaces
> 01 bConfigurationValue
> 00 iConfiguration
> 80 bmAttributes
> 7D bmAttributes
>
> ----- Interface Descriptor -----
> 09 bLength
> 04 bDesc Type
> 00 bInterfaceNumber
> 00 bAlternateSetting
> 02 bNumEndpoints
> 03 bInterfaceClass
> 00 bInterfaceClass
> 00 bInterfaceProtocol
> 00 iInterface
>
> ----- HID Class Descriptor -----
> 09 bLength
> 21 bDesc Type
> 00 02 bcdHID (Hid Spec Release Number) (LSB, MSB)
> 00 bCountryCode (Country code (0x00 for not supported))
> 01 bNumDescriptors (Number of class descriptors)
> 22 bDescriptorType (Report descriptor type)
> 20 00 bDescriptorLength (Report descriptor type) (LSB, MSB)
>
> ----- Endpoint Descriptor -----
> 07 bLength
> 05 bDesc Type
> 81 bEndpointAddress
> 03 bmAttributes
> 40 00 wMaxPacketSize (LSB, MSB)
> 01 bInterval
>
> ----- Endpoint Descriptor -----
> 07 bLength
> 05 bDesc Type
> 01 bEndpointAddress
> 03 bmAttributes
> 40 00 wMaxPacketSize (LSB, MSB)
> 01 bInterval
>
> ----- Interface Descriptor -----
> 09 bLength
> 04 bDesc Type
> 01 bInterfaceNumber
> 00 bAlternateSetting
> 02 bNumEndpoints
> FF bInterfaceClass
> 00 bInterfaceClass
> 00 bInterfaceProtocol
> 00 iInterface
>
> ----- Endpoint Descriptor -----
> 07 bLength
> 05 bDesc Type
> 82 bEndpointAddress
> 02 bmAttributes
> 40 00 wMaxPacketSize (LSB, MSB)
> 00 bInterval
>
> ----- Endpoint Descriptor -----
> 07 bLength
> 05 bDesc Type
> 02 bEndpointAddress
> 02 bmAttributes
> 40 00 wMaxPacketSize (LSB, MSB)
> 00 bInterval
>
>
>
>
> On Wed, Jul 12, 2023 at 8:35 PM Xiaofan Chen <xia...@gm...> wrote:
>>
>> There is no limitation for your use case. Open the device normally and claim the
>> correct interface (interface 1 in your case).
>>
>>  libusb_detach_kernel_driver() is not supported under Windows so it is
>> not relevant.
>>
>> The limitations are mainly with things like IAD and CDC-ACM, not your use case.
>> 1) https://github.com/libusb/libusb/pull/965 (PR merged, it will be in
>> future 1.0.27 release)
>> 2) https://github.com/libusb/libusb/issues/1238
>>
>> Best regards,
>> Xiaofan
>>

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

[RisingEdgeIndustries <su...@ri...>]

Hi Tim,

Thank you very much for the reply! That is what I was loosely gathering
from some github posts and stack overflow posts.  My mission statement was
to *create a composite device with HID and bulk interfaces that was INF
free*.  To accomplish this I thought all I had to do was figure out the MS
OS descriptors which I did.  [Thank you Xciafan Chen for helping me with
that].

There are multiple user space libraries, but libusb1.0 seemed ideal for
this setup of using MS OS descriptors to set my second bulk interface to
WINUSB.  I think I can actually get WINUSB loaded for the entire composite
device.  I accidentally was doing this at one point in my development I
think.

So for my mission statement/goal of an INF free plug and play composite
device with these example interfaces is it correct to say my only path
forward is to go WINUSB for the whole composite device?







On Wed, Jul 12, 2023 at 9:05 PM Tim Roberts <ti...@pr...> wrote:

> On 7/12/23 6:13 PM, RisingEdgeIndustries wrote:
>
> >
> > I've been reading quite a bit of posts online about libusb and
> > composite devices and the challenge due to windows assigning
> > usbccgp.sys which acts as a "parent" driver with the individual
> > interfaces appearing as separate devices.  I have a basic example to
> > better understand libusb1.0 consisting of the following:
> >
> > USB Composite device -- default windows usbccgp.sys driver
> >     Interface 0 - HID interface with Windows HID driver auto loaded
> >     Interface 1 - custom bulk interface with WINUSB driver
> >
> > I've managed to get my descriptors straightened out to auto load the
> > drivers I need and I assumed I could just use
> > libusb's claim_interface() call to choose between my HID or bulk
> > interface.  I now see that (I think) this is not the intended use
> > because the parent driver seems to cause problems.  So I'm wondering
> > if someone could clarify the correct approach to connect and transfer
> > data for a composite device on Windows 10 in this situation with two
> > interfaces.
> >
> > 1. What is the intended implementation in a situation like this?
>
> In the Windows driver model, bus drivers create "device objects", and
> the PnP system finds drivers for any device objects that do not have
> them.  The USB host controller driver will create a device object for
> the composite device.  If you do nothing else, usbccgp will be assigned
> to drive that device.  It will then create two device objects, one for
> each interface.  usbhid will be automatically assigned to the HID
> device, and (presumably) WinUSB will be assigned to the bulk
> interface.   Because of the way usbccgp works, your "interface 1" will
> be fooled into thinking there is only one interface.  This is the
> low-impact solution.
>
> Now, the alternative is to create an INF that claims the composite
> device for WinUSB.  In that case, your INF would cause WinUSB to be
> loaded for that device object.  It does not create any child devices, so
> that's the end of driver loading.  libusb would then have access to both
> interfaces, but usbhid would not be loaded, so the HID interface would
> not be exposed as a HID device.
>
>
> > 2. Since both the HID and bulk interfaces show up as devices (in
> > windows) with the same VID/PID how should one connect to a specific
> > one?  Is claim_interface() the correct approach?
>
> If you use usbccgp and the usbhid, then you will be not able to reach
> the HID interface.  You will only have access to the bulk interface.
>
>
> > 3. I read that some people use libusb_detach_kernel_driver() but that
> > is only for linux from what I see in the documentation - is that
> > correct currently? Just ask because I saw quite a few posts about this.
> libusb_detach_kernel_driver is only available on Linux.  The Windows
> kernel simply does not have this concept.  WIndows only assigns drivers
> through PnP and INF files.
>
> --
> Tim Roberts, ti...@pr...
> Providenza & Boekelheide, Inc.
>
>
>
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

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

[Tim R. <ti...@pr...>]

On 7/12/23 6:13 PM, RisingEdgeIndustries wrote:

>
> I've been reading quite a bit of posts online about libusb and 
> composite devices and the challenge due to windows assigning 
> usbccgp.sys which acts as a "parent" driver with the individual 
> interfaces appearing as separate devices.  I have a basic example to 
> better understand libusb1.0 consisting of the following:
>
> USB Composite device -- default windows usbccgp.sys driver
>     Interface 0 - HID interface with Windows HID driver auto loaded
>     Interface 1 - custom bulk interface with WINUSB driver
>
> I've managed to get my descriptors straightened out to auto load the 
> drivers I need and I assumed I could just use 
> libusb's claim_interface() call to choose between my HID or bulk 
> interface.  I now see that (I think) this is not the intended use 
> because the parent driver seems to cause problems.  So I'm wondering 
> if someone could clarify the correct approach to connect and transfer 
> data for a composite device on Windows 10 in this situation with two 
> interfaces.
>
> 1. What is the intended implementation in a situation like this?

In the Windows driver model, bus drivers create "device objects", and 
the PnP system finds drivers for any device objects that do not have 
them.  The USB host controller driver will create a device object for 
the composite device.  If you do nothing else, usbccgp will be assigned 
to drive that device.  It will then create two device objects, one for 
each interface.  usbhid will be automatically assigned to the HID 
device, and (presumably) WinUSB will be assigned to the bulk 
interface.   Because of the way usbccgp works, your "interface 1" will 
be fooled into thinking there is only one interface.  This is the 
low-impact solution.

Now, the alternative is to create an INF that claims the composite 
device for WinUSB.  In that case, your INF would cause WinUSB to be 
loaded for that device object.  It does not create any child devices, so 
that's the end of driver loading.  libusb would then have access to both 
interfaces, but usbhid would not be loaded, so the HID interface would 
not be exposed as a HID device.


> 2. Since both the HID and bulk interfaces show up as devices (in 
> windows) with the same VID/PID how should one connect to a specific 
> one?  Is claim_interface() the correct approach?

If you use usbccgp and the usbhid, then you will be not able to reach 
the HID interface.  You will only have access to the bulk interface.


> 3. I read that some people use libusb_detach_kernel_driver() but that 
> is only for linux from what I see in the documentation - is that 
> correct currently? Just ask because I saw quite a few posts about this.
libusb_detach_kernel_driver is only available on Linux.  The Windows 
kernel simply does not have this concept.  WIndows only assigns drivers 
through PnP and INF files.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

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

[RisingEdgeIndustries <su...@ri...>]

So I'm taking the same approach I take when I had these interfaces running
as stand alone devices.  My process is below.


Call get_device_list()
Loop through device list to find VID/PID
Once found open_device() with my VID/PID
[at this point I get string descriptors and max_packet_size() which works
fin]
I then execute claim_interface() for my device

I can claim interface 0, but when I try interface 1 I get the following
error:
ERROR: failed to claim interface, ret val = -12
ERROR: code - b'Operation not supported or unimplemented on this platform'

I know from the descriptors during enumeration my second interface is my
bulk interface with bInterfaceNumber "1".

I see both interfaces with correct VID/PID in device manager with correct
drivers and no icons indicating a problem.  Is there something obvious I'm
missing in this process?  This process works fine for non-composite HID
only or bulk only.


*Descriptor data:*


----- Device Descriptor -----
12 bLength
01 bDesc Type
00 02 bcdUSB (LSB, MSB)
00 bDeviceClass
00 bDeviceSubClass
00 bDeviceProtocol
40 bMaxPacketSize0 - Maximum packet size for Endpoint zero (only 8, 16, 32,
or 64 are valid).
BF 1C idVendor (LSB, MSB)
07 00 idProduct (LSB, MSB)
00 01 bcdDevice (BCD) (LSB, MSB)
01 iManufacturer (string index)
02 iProduct (string index)
03 iSerialNumber (string index)
01 bNumConfigurations (string index)

----- Configuration Descriptor -----
09 bLength
02 bDesc Type
40 00 wTotalLen  (LSB, MSB)
02 bNumInterfaces
01 bConfigurationValue
00 iConfiguration
80 bmAttributes
7D bmAttributes

----- Interface Descriptor -----
09 bLength
04 bDesc Type
00 bInterfaceNumber
00 bAlternateSetting
02 bNumEndpoints
03 bInterfaceClass
00 bInterfaceClass
00 bInterfaceProtocol
00 iInterface

----- HID Class Descriptor -----
09 bLength
21 bDesc Type
00 02 bcdHID (Hid Spec Release Number) (LSB, MSB)
00 bCountryCode (Country code (0x00 for not supported))
01 bNumDescriptors (Number of class descriptors)
22 bDescriptorType (Report descriptor type)
20 00 bDescriptorLength (Report descriptor type) (LSB, MSB)

----- Endpoint Descriptor -----
07 bLength
05 bDesc Type
81 bEndpointAddress
03 bmAttributes
40 00 wMaxPacketSize (LSB, MSB)
01 bInterval

----- Endpoint Descriptor -----
07 bLength
05 bDesc Type
01 bEndpointAddress
03 bmAttributes
40 00 wMaxPacketSize (LSB, MSB)
01 bInterval

----- Interface Descriptor -----
09 bLength
04 bDesc Type
01 bInterfaceNumber
00 bAlternateSetting
02 bNumEndpoints
FF bInterfaceClass
00 bInterfaceClass
00 bInterfaceProtocol
00 iInterface

----- Endpoint Descriptor -----
07 bLength
05 bDesc Type
82 bEndpointAddress
02 bmAttributes
40 00 wMaxPacketSize (LSB, MSB)
00 bInterval

----- Endpoint Descriptor -----
07 bLength
05 bDesc Type
02 bEndpointAddress
02 bmAttributes
40 00 wMaxPacketSize (LSB, MSB)
00 bInterval




On Wed, Jul 12, 2023 at 8:35 PM Xiaofan Chen <xia...@gm...> wrote:

> There is no limitation for your use case. Open the device normally and
> claim the
> correct interface (interface 1 in your case).
>
>  libusb_detach_kernel_driver() is not supported under Windows so it is
> not relevant.
>
> The limitations are mainly with things like IAD and CDC-ACM, not your use
> case.
> 1) https://github.com/libusb/libusb/pull/965 (PR merged, it will be in
> future 1.0.27 release)
> 2) https://github.com/libusb/libusb/issues/1238
>
> Best regards,
> Xiaofan
>
>
> On Thu, Jul 13, 2023 at 9:16 AM RisingEdgeIndustries
> <su...@ri...> wrote:
> >
> > Hello,
> >
> > I've been reading quite a bit of posts online about libusb and composite
> devices and the challenge due to windows assigning usbccgp.sys which acts
> as a "parent" driver with the individual interfaces appearing as separate
> devices.  I have a basic example to better understand libusb1.0 consisting
> of the following:
> >
> > USB Composite device -- default windows usbccgp.sys driver
> >     Interface 0 - HID interface with Windows HID driver auto loaded
> >     Interface 1 - custom bulk interface with WINUSB driver
> >
> > I've managed to get my descriptors straightened out to auto load the
> drivers I need and I assumed I could just use libusb's claim_interface()
> call to choose between my HID or bulk interface.  I now see that (I think)
> this is not the intended use because the parent driver seems to cause
> problems.  So I'm wondering if someone could clarify the correct approach
> to connect and transfer data for a composite device on Windows 10 in this
> situation with two interfaces.
> >
> > 1. What is the intended implementation in a situation like this?
> > 2. Since both the HID and bulk interfaces show up as devices (in
> windows) with the same VID/PID how should one connect to a specific one?
> Is claim_interface() the correct approach?
> > 3. I read that some people use libusb_detach_kernel_driver() but that is
> only for linux from what I see in the documentation - is that correct
> currently?  Just ask because I saw quite a few posts about this.
> >
> > I have both interfaces working as standalone projects so I think I'm
> pretty close, but the composite case isn't as straightforward as I thought.
> >
> > Thank you for the support and libusb!
> >
> > _______________________________________________
> > libusb-devel mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

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

[Xiaofan C. <xia...@gm...>]

There is no limitation for your use case. Open the device normally and claim the
correct interface (interface 1 in your case).

 libusb_detach_kernel_driver() is not supported under Windows so it is
not relevant.

The limitations are mainly with things like IAD and CDC-ACM, not your use case.
1) https://github.com/libusb/libusb/pull/965 (PR merged, it will be in
future 1.0.27 release)
2) https://github.com/libusb/libusb/issues/1238

Best regards,
Xiaofan


On Thu, Jul 13, 2023 at 9:16 AM RisingEdgeIndustries
<su...@ri...> wrote:
>
> Hello,
>
> I've been reading quite a bit of posts online about libusb and composite devices and the challenge due to windows assigning usbccgp.sys which acts as a "parent" driver with the individual interfaces appearing as separate devices.  I have a basic example to better understand libusb1.0 consisting of the following:
>
> USB Composite device -- default windows usbccgp.sys driver
>     Interface 0 - HID interface with Windows HID driver auto loaded
>     Interface 1 - custom bulk interface with WINUSB driver
>
> I've managed to get my descriptors straightened out to auto load the drivers I need and I assumed I could just use libusb's claim_interface() call to choose between my HID or bulk interface.  I now see that (I think) this is not the intended use because the parent driver seems to cause problems.  So I'm wondering if someone could clarify the correct approach to connect and transfer data for a composite device on Windows 10 in this situation with two interfaces.
>
> 1. What is the intended implementation in a situation like this?
> 2. Since both the HID and bulk interfaces show up as devices (in windows) with the same VID/PID how should one connect to a specific one?  Is claim_interface() the correct approach?
> 3. I read that some people use libusb_detach_kernel_driver() but that is only for linux from what I see in the documentation - is that correct currently?  Just ask because I saw quite a few posts about this.
>
> I have both interfaces working as standalone projects so I think I'm pretty close, but the composite case isn't as straightforward as I thought.
>
> Thank you for the support and libusb!
>
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

[libusb] Correct use of libusb with composite device

[RisingEdgeIndustries <su...@ri...>]

Hello,

I've been reading quite a bit of posts online about libusb and composite
devices and the challenge due to windows assigning usbccgp.sys which acts
as a "parent" driver with the individual interfaces appearing as separate
devices.  I have a basic example to better understand libusb1.0 consisting
of the following:

USB Composite device -- default windows usbccgp.sys driver
    Interface 0 - HID interface with Windows HID driver auto loaded
    Interface 1 - custom bulk interface with WINUSB driver

I've managed to get my descriptors straightened out to auto load the
drivers I need and I assumed I could just use libusb's claim_interface()
call to choose between my HID or bulk interface.  I now see that (I think)
this is not the intended use because the parent driver seems to cause
problems.  So I'm wondering if someone could clarify the correct approach
to connect and transfer data for a composite device on Windows 10 in this
situation with two interfaces.

1. What is the intended implementation in a situation like this?
2. Since both the HID and bulk interfaces show up as devices (in windows)
with the same VID/PID how should one connect to a specific one?  Is
claim_interface() the correct approach?
3. I read that some people use libusb_detach_kernel_driver() but that is
only for linux from what I see in the documentation - is that correct
currently?  Just ask because I saw quite a few posts about this.

I have both interfaces working as standalone projects so I think I'm pretty
close, but the composite case isn't as straightforward as I thought.

Thank you for the support and libusb!

Re: [libusb] Help with arch: USB Composite HID Dev Class and Bulk Interface

[Xiaofan C. <xia...@gm...>]

I am not an expert in this area but I can point you to two examples using
Microsoft OS 2.0 Descriptors with USB Composite Devices. I am not so sure
if they are the best examples or not but both of them work well.

1) Raspberry Pi PIcoProbe: one custom interface plus one CDC-ACM interface
https://github.com/raspberrypi/picoprobe/blob/master/src/usb_descriptors.c

2) USBAsp with one custom interfaces and  two HID interfaces
https://github.com/dioannidis/usbasp/blob/master/firmware/usb_descriptors.h

USBTreeView of the USBasp example.

*
      ======================== USB Device ========================

        +++++++++++++++++ Device Information ++++++++++++++++++
Device Description       : USB Composite Device
Device Path              :
\\?\USB#VID_16C0&PID_05DC#0000#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
(GUID_DEVINTERFACE_USB_DEVICE)
Kernel Name              : \Device\USBPDO-8
Device ID                : USB\VID_16C0&PID_05DC\0000
Hardware IDs             : USB\VID_16C0&PID_05DC&REV_0111 USB\VID_16C0&PID_05DC
Driver KeyName           : {36fc9e60-c465-11cf-8056-444553540000}\0028
(GUID_DEVCLASS_USB)
Driver                   : \SystemRoot\System32\drivers\usbccgp.sys
(Version: 10.0.22621.1194  Date: 2023-02-15)
Driver Inf               : C:\WINDOWS\inf\usb.inf
Legacy BusType           : PNPBus
Class                    : USB
Class GUID               : {36fc9e60-c465-11cf-8056-444553540000}
(GUID_DEVCLASS_USB)
Service                  : usbccgp
Enumerator               : USB
Location Info            : Port_#0001.Hub_#0002
Location IDs             : PCIROOT(0)#PCI(1400)#USBROOT(0)#USB(1),
ACPI(_SB_)#ACPI(PC00)#ACPI(XHCI)#ACPI(RHUB)#ACPI(HS01)
Container ID             : {58d5dbb6-da7f-596f-9685-64e8204fdb5e}
Manufacturer Info        : (Standard USB Host Controller)
Capabilities             : 0x94 (Removable, UniqueID, SurpriseRemovalOK)
Status                   : 0x0180600A (DN_DRIVER_LOADED, DN_STARTED,
DN_DISABLEABLE, DN_REMOVABLE, DN_NT_ENUMERATOR, DN_NT_DRIVER)
Problem Code             : 0
Address                  : 1
HcDisableSelectiveSuspend: 0
EnableSelectiveSuspend   : 0
SelectiveSuspendEnabled  : 0
EnhancedPowerMgmtEnabled : 0
IdleInWorkingState       : 0
WakeFromSleepState       : 0
Power State              : D0 (supported: D0, D3, wake from D0)
 Child Device 1          : USBasp (WinUsb Device)
  Device Path 1          :
\\?\USB#VID_16C0&PID_05DC&MI_00#6&139af701&2&0000#{ad57d3b9-1166-43f8-8790-0be14ddc7504}
  Device Path 2          :
\\?\USB#VID_16C0&PID_05DC&MI_00#6&139af701&2&0000#{dee824ef-729b-4a0e-9c14-b7117d33a817}
(GUID_DEVINTERFACE_WINUSB)
  Kernel Name            : \Device\00000135
  Device ID              : USB\VID_16C0&PID_05DC&MI_00\6&139AF701&2&0000
  Class                  : USBDevice
  Driver KeyName         : {88bae032-5a81-49f0-bc3d-a4ff138216d6}\0004
(GUID_DEVCLASS_USBDEVICE)
  Service                : WINUSB
  Location               : 0000.0014.0000.001.000.000.000.000.000
  LocationPaths          :
PCIROOT(0)#PCI(1400)#USBROOT(0)#USB(1)#USBMI(0)
PCIROOT(0)#PCI(1400)#USBROOT(0)#USB(1)#USB(1)
ACPI(_SB_)#ACPI(PC00)#ACPI(XHCI)#ACPI(RHUB)#ACPI(HS01)#USBMI(0)
ACPI(_SB_)#ACPI(PC00)#ACPI(XHCI)#ACPI(RHUB)#ACPI(HS01)#USB(1)
 Child Device 2          : USB Input Device
  Device ID              : USB\VID_16C0&PID_05DC&MI_01\6&139AF701&2&0001
  Class                  : HIDClass
  Driver KeyName         : {745a17a0-74d3-11d0-b6fe-00a0c90f57da}\0029
(GUID_DEVCLASS_HIDCLASS)
  Service                : HidUsb
  Location               : 0000.0014.0000.001.000.000.000.000.000
  LocationPaths          :
PCIROOT(0)#PCI(1400)#USBROOT(0)#USB(1)#USBMI(1)
ACPI(_SB_)#ACPI(PC00)#ACPI(XHCI)#ACPI(RHUB)#ACPI(HS01)#USBMI(1)
   Child Device 1        : HID-compliant vendor-defined device
    Device Path          :
\\?\HID#VID_16C0&PID_05DC&MI_01#7&30dbfe15&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
(GUID_DEVINTERFACE_HID)
    Kernel Name          : \Device\00000138
    Device ID            : HID\VID_16C0&PID_05DC&MI_01\7&30DBFE15&0&0000
    Class                : HIDClass
    Driver KeyName       : {745a17a0-74d3-11d0-b6fe-00a0c90f57da}\0031
(GUID_DEVCLASS_HIDCLASS)
 Child Device 3          : USB Input Device
  Device ID              : USB\VID_16C0&PID_05DC&MI_02\6&139AF701&2&0002
  Class                  : HIDClass
  Driver KeyName         : {745a17a0-74d3-11d0-b6fe-00a0c90f57da}\0030
(GUID_DEVCLASS_HIDCLASS)
  Service                : HidUsb
  Location               : 0000.0014.0000.001.000.000.000.000.000
  LocationPaths          :
PCIROOT(0)#PCI(1400)#USBROOT(0)#USB(1)#USBMI(2)
ACPI(_SB_)#ACPI(PC00)#ACPI(XHCI)#ACPI(RHUB)#ACPI(HS01)#USBMI(2)
   Child Device 1        : HID-compliant vendor-defined device
    Device Path          :
\\?\HID#VID_16C0&PID_05DC&MI_02#7&d04c053&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
(GUID_DEVINTERFACE_HID)
    Kernel Name          : \Device\00000139
    Device ID            : HID\VID_16C0&PID_05DC&MI_02\7&D04C053&0&0000
    Class                : HIDClass
    Driver KeyName       : {745a17a0-74d3-11d0-b6fe-00a0c90f57da}\0032
(GUID_DEVCLASS_HIDCLASS)

*


Best regards,
Xiaofan

Re: [libusb] OT: Stuck at "Device was not migrated due to partial or ambiguous match."

[Tim R. <ti...@pr...>]

Kustaa Nyholm wrote:
>
> This is a semi hobby project for me and the users so I'm not sure the 
> user is against hacking his machine.
>
> So, what keys should/could be removed from registry?
>
> Definitely my systems should not care if the device settings are 
> migrated or not (I was not even aware there
>
> were device settings related to a simple generic HID device where (as 
> far as OS is concerned) the only
>
> functionality is that the device is capable to send and receive 64 
> byte chunks of bytes.
>
The device instance names you see come from the registry keys. That's 
how Windows knows it has seen this device before.

HKLM\System\CurrentControlSet\Enum\USB\VID_...

HKLM\System\CurrentControlSet\Enum\HID\VID_...

-- 
Tim Roberts,ti...@pr...
Providenza & Boekelheide, Inc.

Re: [libusb] OT: Stuck at "Device was not migrated due to partial or ambiguous match."

[RisingEdgeIndustries <su...@ri...>]

So I have actually done some removal with the following paths, but I'm
pretty new so not sure how much is missing or if one of these is
unnecessary.

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbstor
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags

In flags folder the subfolders are VIDPID and I deleted all the entries in
there.  This allowed my device to re-enumerate fresh or at least it looked
that way for me to do testing.

Robbie Valentine
Electrical Engineer
RisingEdgeIndustries
(256) 244-4091


On Tue, Jul 4, 2023 at 5:23 AM Kustaa Nyholm <Kus...@pl...>
wrote:

> Thank Tim, re hacking the registry.
>
>
>
> This is a semi hobby project for me and the users so I'm not sure the user
> is against hacking his machine.
>
>
>
> So, what keys should/could be removed from registry?
>
>
>
> Definitely my systems should not care if the device settings are migrated
> or not (I was not even aware there
>
> were device settings related to a simple generic HID device where (as far
> as OS is concerned) the only
>
> functionality is that the device is capable to send and receive 64 byte
> chunks of bytes.
>
>
>
> wbr  Kusti
>
>
>
>
>
>
>
>
>
> *From: *Tim Roberts <ti...@pr...>
> *Date: *Monday, 3. July 2023 at 21.16
> *To: *lib...@li... <
> lib...@li...>
> *Subject: *Re: [libusb] OT: Stuck at "Device was not migrated due to
> partial or ambiguous match."
>
> Hmm.  I don't understand that at all.  If you do an "uninstall", that
> should remove the vestiges of the old installation and start over.  If I
> had the system, I would hack the registry to remove the old instance, but
> that's not acceptable on a customer system.
>
>
>
> Does the device work?  You probably don't care if the device settings were
> migrated, as long as it operates.  Is this just an annoying warning?
>
>
>
> Perhaps the [NTDEV] folks can give you a clue.
>
> --
>
> Tim Roberts, ti...@pr...
>
> Providenza & Boekelheide, Inc.
>
>
>
>
>
> Kustaa Nyholm wrote:
>
>
>
>
>
> *From: *Tim Roberts <ti...@pr...> <ti...@pr...>
> *Date: *Monday, 3. July 2023 at 3.19
> *To: *lib...@li...
> <lib...@li...> <lib...@li...>
> *Subject: *Re: [libusb] OT: Stuck at "Device was not migrated due to
> partial or ambiguous match."
>
> There are two device objects involved here, and hence two listings in
> Device Manager.  There is a USB device, which has the format
> USB\VID_xxxx&PID_xxxx&REV_0100\....  That should have automatically loaded
> usbhid.sys, which then creates more devices for your top-level collection,
> which should have th format HID\VID_xxxx&PID_xxxx&REV_xxxx&COL_01.  If your
> device has a yellow bang icon in Device Manager, which one is it?
>
> This what my user reported when I asked your question:
>
>
>
> Yes, 2 new items appear when Toad4 is plugged in.
>
> The first one is "HID-compliant vendor-defined device", Information is:
>
>
>
> Device settings for HID\VID_1D50&PID_6020\6&2801700&1&0000 were not
> migrated from previous OS installation due to partial or ambiguous device
> match.
> Last Device Instance Id: USB\VID_17EF&PID_6019\5&2059b984&0&2
> Class Guid: {745a17a0-74d3-11d0-b6fe-00a0c90f57da}
> Location Path:
> Migration Rank: 0xF000FFFFFFFFF120
> Present: false
> Status: 0xC0000719
>
>
>
> The second one is "USB Input Device", Information is:
>
>
>
> Device settings for USB\VID_1D50&PID_6020\0000363 were not migrated from
> previous OS installation due to partial or ambiguous device match.
> Last Device Instance Id: USB\VID_17EF&PID_6019\5&2059b984&0&2
> Class Guid: {745a17a0-74d3-11d0-b6fe-00a0c90f57da}
> Location Path:
> Migration Rank: 0xF000FFFFFC00F130
> Present: false
> Status: 0xC0000719
>
>
>
> There is no yellow icron showing.
>
> It looks like both USB\VID and HID\VID are not quite right.
>
>
>
>
>
> This e-mail may contain confidential or privileged information and is
> intended solely for the person to whom it is addressed. If you have
> received this e-mail in error, please notify the sender immediately and
> destroy this e-mail. Any unauthorized copying, disclosure or distribution
> of the material in this e-mail is strictly forbidden. We will not be liable
> for direct, indirect, special or consequential damages arising from the
> alteration of this e-mail, or as a result of any virus being passed on or
> as of transmission of this e-mail in general.
>
>
> _______________________________________________
>
> libusb-devel mailing list
>
> lib...@li...
>
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>
>
> This e-mail may contain confidential or privileged information and is
> intended solely for the person to whom it is addressed. If you have
> received this e-mail in error, please notify the sender immediately and
> destroy this e-mail. Any unauthorized copying, disclosure or distribution
> of the material in this e-mail is strictly forbidden. We will not be liable
> for direct, indirect, special or consequential damages arising from the
> alteration of this e-mail, or as a result of any virus being passed on or
> as of transmission of this e-mail in general.
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

Re: [libusb] Help with arch: USB Composite HID Dev Class and Bulk Interface

[Xiaofan C. <xia...@gm...>]

You should be able to achieve what you want.

USB Composite Device -- default Windows usbccgp.sys driver.
Interface 0 -- custom interface and with WInUSB driver automatically loaded
Interface 1 -- HID interface with Windows HID driver automatically loaded.

Read the following document and hopefully you will be able to figure
things out by yourself, basically you can specify the interface number for
which
the Microsoft OS 2.0 function subset header is applicable.
https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/microsoft-os-2-0-descriptors-specification

Microsoft OS 2.0 function subset header

Table 12. Function subset header

*Offset*

*Field*

*Size*

*Description*

0

*wLength*

2

The length, in bytes, of this subset header. Shall be set to 8.

2

*wDescriptorType*

2

MS_OS_20_SUBSET_HEADER_FUNCTION

4

*bFirstInterface*

1

The interface number for the first interface of the function to which this
subset applies.

5

*bReserved*

1

Shall be set to 0.

6

*wSubsetLength*

2

The size of entire function subset including this header.


Best regards,
Xiaofan

On Tue, Jul 4, 2023 at 10:43 AM RisingEdgeIndustries <
su...@ri...> wrote:

> Hello,
>
> I've been using libusb 1.0 for bulk interface transfers which has worked
> wonderfully.  I read that for hid devices, hidapi is best and now part of
> libusb so I used that for my hid device class project.  These were two
> separate physical devices (firmware projects) originally and worked great.
>
> The goal of the effort was to have HID and bulk interfaces enumerate with
> either full driver support or at least windows kernel driver support
> (winusb.sys) on their own without having to install any INF files.  This
> also worked great because HID enumerates fine on its own and the bulk
> interface used the Microsoft OS string descriptors to load the winusb.sys
> kernel driver.
>
> I'm now trying to combine the HID device class (interface) and the bulk
> interface into a single composite device.  The goal is that they exhibit
> the same plug and play nature and work out of the box at least up to the
> kernel driver.
>
> My test composite project has shown me that I can negotiate MS OS
> descriptors for the composite device but then winusb.sys owns the entire
> device and I'd have to use libusb1.0 for both interfaces (HID and Bulk) and
> from what I've read the last few days about this from the community it
> sounds like you shouldn't use libusb for HID.  I should use winusb.sys and
> libusb for bulk and hidapi for HID.  If I don't respond to the MS OS
> descriptors then windows loads usbgcc.sys composite driver (I think) by
> default and attempts to enumerate the interfaces as two separate devices.
> This is pretty appealing (and seems to work for HID), but without the MS OS
> descriptors my bulk interface won't get associated with winusb.sys and it
> won't work.
>
> So long story short it seems like you can either load winusb.sys for the
> whole composite device via MS OS string descriptors or usbgcc.sys for the
> composite device allowing each interface to enumerate independently.  The
> problem here is that the MS OS descriptor exchange doesn't happen in this
> second case.
>
> My goal is to get the HID and bulk interfaces up and running like before
> (when the usb device projects were separate) but as a composite device
> where HID loads completely as a HID device without user intervention and
> the bulk interface gets the winusb.sys kernel driver associated with it so
> I can use libusb1.0.  I assume there is a higher level
> architecture/descriptor approach I'm missing  because I'm not an
> experienced USB developer.
>
> I've attached a block diagram showing what I'm ultimately trying to
> achieve.  How should I approach this if my goal is a composite device with
> HID and BULK that is "plug and play" up to the kernel driver at a minimum
> similar to how the current projects work as standalone usb devices?  Is it
> possible to execute the MS OS string descriptor negotiation just for the
> bulk interface so I can then use libusb?
>
> Also, is there something I'm missing about libusb where it could work for
> both interfaces in one of these scenarios?
>
> Thanks for any advice!
>
>
> [image: image.png]
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

Re: [libusb] (no subject)

[Xiaofan C. <xia...@gm...>]

You can do that by yourself.

Please go to the following website and unsubscribe by yourself.
https://sourceforge.net/projects/libusb/lists/libusb-devel

Best regards,
Xiaofan

On Tue, Jul 4, 2023 at 7:09 PM Kyle Chesshir <kch...@di...> wrote:

> Please remove me from the email list.
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows
>
>
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>