SET_INTERFACE.

NTDEV
1

Hi,

I am trying to emulate the ms usb hub driver. I do this by creating usb devices on my bus and receiving urbs from them.

The problem occurs after a set config with a printer I am testing. It appears that the printer does not set intf 0 alt 0 as other devices do by default. A filter driver that I attached below the device captures a set config sent to the ms hub and then captures nothing after that. But I see a set interface being issued to the printer (via a usb analyzer).

This is a long shot, but does anyone know if the ms hub driver itself issues the set interface.

Thanks,

Kevin.

2

xxxxx@gmail.com wrote:

I am trying to emulate the ms usb hub driver. I do this by creating usb devices on my bus and receiving urbs from them.

The problem occurs after a set config with a printer I am testing. It appears that the printer does not set intf 0 alt 0 as other devices do by default. A filter driver that I attached below the device captures a set config sent to the ms hub and then captures nothing after that. But I see a set interface being issued to the printer (via a usb analyzer).

This is a long shot, but does anyone know if the ms hub driver itself issues the set interface.

SET_CONFIGURATION automatically does a SET_INTERFACE for interface 0.
When there is only one interface with no alternate settings, it’s quite
common to omit the SET_INTERFACE URB.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Hi,

This works fine.

However, when I plugin an Epson USB adapter, I see that the hub sets intf 0 alt 1.

Any thoughts?

4

xxxxx@gmail.com wrote:

However, when I plugin an Epson USB adapter, I see that the hub sets intf 0 alt 1.

Any thoughts?

Any thoughts about what? The hub doesn’t select interfaces on its own.
It only does so in response to a driver request.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

I have attached a filter driver below the device pdo, and I don’t see any set interface requests being sent to the hub driver. But I do see set interface requests being sent down to the device. So I assumed that the hub driver does this.

And as you said:

– SET_CONFIGURATION automatically does a SET_INTERFACE for interface 0. When there is only one – interface with no alternate settings, it’s quite common to omit the SET_INTERFACE URB.

So who does the set interface?

6

xxxxx@gmail.com wrote:

I have attached a filter driver below the device pdo, and I don’t see any set interface requests being sent to the hub driver. But I do see set interface requests being sent down to the device. So I assumed that the hub driver does this.

And as you said:

– SET_CONFIGURATION automatically does a SET_INTERFACE for interface 0. When there is only one – interface with no alternate settings, it’s quite common to omit the SET_INTERFACE URB.

So who does the set interface?

Have you ever written a USB client driver? If you have, you should have
encountered this. If you haven’t, I don’t see how you can ever hope to
write a USB filter driver.

The URB_SELECT_INTERFACE structure includes a configuration handle (as
input), and a USBD_INTERFACE_INFORMATION structure that specifies which
interface and alternate setting to choose. The URB_SELECT_CONFIGURATION
structure includes a configuration descriptor, a configuration handle
(as output), and a list of USBD_INTERFACE_INFORMATION structures that
specify which interface(s) and alternate setting(s) to choose.

In response to URB_SELECT_CONFIGURATION, the host controller driver will
issue a SET_CONFIGURATION packet, and one or more SET_INTERFACE packets.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

I know that URB_SELECT_CONFIGURATION has a config and one or more USBD_INTERFACE_INFORMATION structures.

Do you mean to say that in a URB_SELECT_CONFIGURATION, if 3 alt settings come down in 3 USBD_INTERFACE_INFORMATION elements that the host controller driver will send a SET_CONFIGURATION packet followed by 3 SET_INTERFACE packets down to the device?

I see 3 alts coming down, and see the host controller driver sending a SET_CONFIGURATION and only one SET_INTERFACE down to the device. Also, one device gets alt 0 and another gets alt 1. How does the host controller driver know which alt to select?

The fact of the matter is, that I am trying to write a driver that emulates what the host controller driver is doing.

8

xxxxx@gmail.com wrote:

I know that URB_SELECT_CONFIGURATION has a config and one or more USBD_INTERFACE_INFORMATION structures.

Do you mean to say that in a URB_SELECT_CONFIGURATION, if 3 alt settings come down in 3 USBD_INTERFACE_INFORMATION elements that the host controller driver will send a SET_CONFIGURATION packet followed by 3 SET_INTERFACE packets down to the device?

Exactly. The URB_SELECT_CONFIGURATION request should contain one entry
for each interface in the configuration, with the desired alternate
setting selected in each one. Most drivers do not deal with multiple
interfaces, so typically the request only contains one interface.

I see 3 alts coming down, and see the host controller driver sending a SET_CONFIGURATION and only one SET_INTERFACE down to the device. Also, one device gets alt 0 and another gets alt 1. How does the host controller driver know which alt to select?

Not sure what you mean by “I see 3 alts coming down”. If a device has
one interface with 3 alternate settings, the URB_SELECT_CONFIGURATION
request will only have one interface entry.

Is this a composite device? That throws a wrinkle into things. The
composite driver (usbccgp.sys) lies to the devices above it, so that
each one thinks it is talking to a single interface device. It then has
to translate what it gets into the proper form for a multi-interface
device.
If the first subdevice happens to pick alternate setting 1, usbccgp
needs to send a URB_SELECT_CONFIGURATION request that has alt setting 1
for that interface, but 0 for the others (which haven’t reported yet).

Is this an audio or video class device, where one interface is fake and
the other interface does all the work?

The fact of the matter is, that I am trying to write a driver that emulates what the host controller driver is doing.

That is a nearly hopeless task. Much of the interaction between the
host controller and the hub drivers is not documented.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

9

> I see 3 alts coming down, and see the host controller driver sending a SET_CONFIGURATION and only one SET_INTERFACE down to the device. Also, one device gets alt 0 and another gets alt 1. How does the host controller driver know which alt to select?

Not sure what you mean by “I see 3 alts coming down”.

– When I get the URB_SELECT_CONFIGURATION it has 3 USBD_INTERFACE_INFORMATION structures each filled with intf 0 and alt 0, 1 or 2.

If a device has one interface with 3 alternate settings, the URB_SELECT_CONFIGURATION request will only have one interface entry.

– This is not the case. And can’t be, because the host controller driver must fill in the PipeHandle information for each endpoint, so that he device driver can use it when making bulk calls etc.

10

xxxxx@gmail.com wrote:

> I see 3 alts coming down, and see the host controller driver sending a SET_CONFIGURATION and only one SET_INTERFACE down to the device. Also, one device gets alt 0 and another gets alt 1. How does the host controller driver know which alt to select?
Not sure what you mean by “I see 3 alts coming down”.

– When I get the URB_SELECT_CONFIGURATION it has 3 USBD_INTERFACE_INFORMATION structures each filled with intf 0 and alt 0, 1 or 2.

That is a bug on the part of the client driver. It doesn’t make sense.
I don’t know what the host controller will do with that, and I’m not
convinced that it’s important.

If a device has one interface with 3 alternate settings, the URB_SELECT_CONFIGURATION request will only have one interface entry.

– This is not the case. And can’t be, because the host controller driver must fill in the PipeHandle information for each endpoint, so that he device driver can use it when making bulk calls etc.

No, you are wrong. Exactly one alternate setting is active at any given
time for each interface. Usually, all of the alternate settings for a
single interface have the same pipes. But if they do not (which is
legal), the pipes that are not present in the active alternate setting
cannot be used. To use a pipe that’s part of a different alternate
setting, the client driver must make another URB_SELECT_INTERFACE call,
and that will return new pipe handles.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

11

You are correct, thanks.

From the MSDN:

An URB_FUNCTION_SELECT_CONFIGURATION URB consists of a _URB_SELECT_CONFIGURATION structure followed by a sequence of variable-length USB_INTERFACE_INFORMATION structures, one USB_INTERFACE_INFORMATION structure for each unique interface number in the configuration. Client drivers must allocate enough memory to contain one USBD_PIPE_INFORMATION structure for each endpoint in the selected interfaces.

I seem to get a USB_INTERFACE_INFORMATION for each alt. I will plug-in different devices and see what happens.