USB Composite Device + Binded to WinUSB Interface

Hi,

We have two interfaces on a USB Device. Both binds to WinUSB Driver and Interface1 presents 0 Endpoints (Billboard) Interface and Interface2 presents 2 Endpoints (Vendor Interface).

The USB Device is under a Hub and when we connect the device Billboard Interface shows Device Power State as D2 and Vendor Interface shows Device Power State as D3.

Which field of descriptor is looked by the WinUSB Driver and Power Manager to put into these states.

How can I make sure both the interfaces into D2 state. The Vendor Interface presents Buld and Interrupt Endpoints.

Regards,
Sudheer

Why does it matter? Any I/O request will bring the device back to D0 from either state. I could understand if you wanted both to go to D3 so you could support selective suspend, but I don’t understand why you’d want both in D2. There’s no useful difference.

Hi Tim,

We would like to put the Hub into D2 / D3 states. As one of the interface was in D0, the Hub Controller can’t enter into D2 / D3 state.

I tried with the same device now, I have Billboard Interface (Binds to WinUSB) + HID Interface (Binds to hidclass driver).

After this change both the interfaces go to D2. And we see a Suspend Packet (USB Packet) on the bus using Lecroy USB Analyzer.

Now, we would like to understand why Vendor Interface which binds to WinUSB can’t go to D2 state.

Based on which part of USB Descriptor WinUSB Driver decides whether it can put the interface / device into D2, D3 and etc…

By the way we are using MS OS Descriptor to bind vendor interface to the WinUSB.

There is no application running on Host Pc which is communicating with Vendor Interface. (This is in response to Any I/O request bring the device back to D0).

let me know in case any thing I can provide for clarifications.

Regards,
Sudheer

OK, I’m officially confused by this thread. I think you haven’t told us the whole story.

In the first message, you said:

… when we connect the device Billboard Interface shows Device Power State as D2 and
Vendor Interface shows Device Power State as D3.

In the last message, you said:

Now, we would like to understand why Vendor Interface which binds to WinUSB can’t go do D2 state.

So, are you saying that the second interface goes into D3 when you use the HID driver, but it stays in D0 when you use WinUSB? Because you never said that. If that’s the core of your problem, one would think that would have been prominent in your first message.

Are you advertising in your configuration descriptor that you support remote wakeup? If so, why?

Have you read the MSDN page about the WinUSB power management registry entries? You can set all of these through your MS extended descriptors.
You will certainly want DeviceIdleEnabled and probably DefaultIdleState.

https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/winusb-power-management

Hi Tim,

Apologies for the below statement. It’s my bad the vendor interface shows D0 only.

@sudheerg_ said:
The USB Device is under a Hub and when we connect the device Billboard Interface shows Device Power State as D2 and Vendor Interface shows Device Power State as D3.

How can I make sure both the interfaces into D2 state. The Vendor Interface presents Bulk and Interrupt Endpoints.

  • Billboard + Vendor Interface Device Power states are as D2 and D0 respectively
  • The descriptors in the same device are modified to present (Billboard + HID Interface) and both the interfaces show the device power states same and in D2.

When I was presenting Billboard + Vendor Interface, I have manually added three registry keys after which the Vendor Interface also enters into D2.

“DeviceIdleEnabled”=dword:00000001
“DeviceIdleIgnoreWakeEnable”=dword:00000001
“DefaultIdleState”=dword:00000001

After adding above keys to the following key path: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_17EF&PID_308D&MI_00\c&1e417bfb&4&0000\Device Parameters], the Vendor Interface also goes to D2.

But, at this point I am trying to understand, what needs to be modified in the Descriptors so that Vendor Interface also can created those keys.
We prefer not to provide this as solution because we have to provide an application which does these modifications on every machine and it will be painful to them.

Hope it clarifies.

Regards,
Sudheer

You said you’re already doing the Microsoft OS extended descriptors, right? If you look in the OS_Desc_Ext_Prop document, which is part of the zip with the extended descriptor spec, you can see how to add arbitrary registry values. See page 10, “Example: Enabling Selective Suspend for a WINUSB Device”.

And as a quick followup, although the title says “enabling selective suspend”, that section includes a list of the other entries you can set, and all of the ones you need are there.

Hi Tim,

Thank you for your time and sorry for my foolishness. I haven’t thought in that way.

Now, if we send all the three Registry Properties through Extended Properties descriptor, the device enters into D2 / D3 state.

Unfortunately, no where MS states what is the right way of doing it.

My only concern is if MS changes something in future then our code will not be compatible.

Once again, thank you very much for your time and pointers.

Those registry entries are all documented, and the extended descriptor mechanism for setting registry entries is documented. There’s no chance this will not work in the future.

Hi Tim,

I forgot to tell one thing, that when we have added the below three keys as part extended properties, we noticed that Windows doesn’t update the Registry unless we remove the registry keys from the Interface-1

“DeviceIdleEnabled”=dword:00000001
“DeviceIdleIgnoreWakeEnable”=dword:00000001
“DefaultIdleState”=dword:00000001

The registry path from where we have to remove all the keys is as below.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_17EF&PID_308D&MI_01\c&1e417bfb&5&0001\Device Parameters

Our OS Descriptor Version is 1.0.
The OS Descriptor Version 2.0 states that the entries are populated only during first time enumeration and subsequent enumerations will not create the registry entries as shown below.

Is there any other method to override this behavior?

Thank You for your time.

Regards,
Sudheer

No. This is only a problem during development, where the inconvenience doesn’t matter. Your end users won’t have the old values.