When USB driver received PnP start device Irp, it will send
set configure Urb to lower driver to configure device.
Before _URB_SELECT_CONFIGURATION is sent, the driver
needs to parse configuration descriptor to prepare one interface
list for all active interfaces.
My question is that if I initialize one of the interface list to alternate
setting 1 instead of 0. After pass the Urb, the driver will get interface
information of alternate setting 1.
What does it mean? Alternate setting 1 is active now??
I can only see set configure command is sent to device.
I don’t think device know alternate setting 1 is active except set interface
command is sent.
If I need to explictly prepare and send _URB_SELECT_INTERFACE urb
to activate alternate setting 1, does it mean I should not prepare the
interface
list of alternate setting 1 for _URB_SELECT_CONFIGURATION urb?
Best Regards
Jack Huang
huangjj wrote:
When USB driver received PnP start device Irp, it will send
set configure Urb to lower driver to configure device.
Before _URB_SELECT_CONFIGURATION is sent, the driver
needs to parse configuration descriptor to prepare one interface
list for all active interfaces.
My question is that if I initialize one of the interface list to alternate
setting 1 instead of 0. After pass the Urb, the driver will get interface
information of alternate setting 1.
What does it mean? Alternate setting 1 is active now??
No, it means that the USB host controller will THINK that alternate
setting 1 has been selected. The best advice in this case is “don’t do
that”. Always pass alternate setting 0 to URB_SELECT_CONFIGURATION.
I can only see set configure command is sent to device.
I don’t think device know alternate setting 1 is active except set interface
command is sent.
Yes, you are correct.
If I need to explictly prepare and send _URB_SELECT_INTERFACE urb
to activate alternate setting 1, does it mean I should not prepare the
interface
list of alternate setting 1 for _URB_SELECT_CONFIGURATION urb?
Yes, that’s what it means. Send the SELECT_CONFIGURATION, then send the
SELECT_INTERFACE to change the alternate setting. Also remember that
SELECT_INTERFACE can fail if there is not enough bandwidth for the
isochronous endpoints in your alternate setting.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks for your help!
I’m just confused by DDK document about _URB_SELECT_CONFIGURATION.
The comment of _URB_SELECT_CONFIGURATION.Interface says:
“Before the request is sent to the host controller driver, the driver may
select
an alternate setting for one or more of the interfaces contained in this
array
by setting members of the USBD_INTERFACE_INFORMATION structure
for that interface.”
Therefore, I try to select alternate setting 1 for set configure request.
But I don’t see select interface command is sent after set configure command
is sent.
I wonder why DDK has this comment.
Best Regards
Jack Huang
“Tim Roberts” …
> huangjj wrote:
>> When USB driver received PnP start device Irp, it will send
>> set configure Urb to lower driver to configure device.
>> Before _URB_SELECT_CONFIGURATION is sent, the driver
>> needs to parse configuration descriptor to prepare one interface
>> list for all active interfaces.
>>
>> My question is that if I initialize one of the interface list to
>> alternate
>> setting 1 instead of 0. After pass the Urb, the driver will get interface
>> information of alternate setting 1.
>> What does it mean? Alternate setting 1 is active now??
>>
>
> No, it means that the USB host controller will THINK that alternate
> setting 1 has been selected. The best advice in this case is “don’t do
> that”. Always pass alternate setting 0 to URB_SELECT_CONFIGURATION.
>
>> I can only see set configure command is sent to device.
>> I don’t think device know alternate setting 1 is active except set
>> interface
>> command is sent.
>>
>
> Yes, you are correct.
>
>> If I need to explictly prepare and send _URB_SELECT_INTERFACE urb
>> to activate alternate setting 1, does it mean I should not prepare the
>> interface
>> list of alternate setting 1 for _URB_SELECT_CONFIGURATION urb?
>>
>
> Yes, that’s what it means. Send the SELECT_CONFIGURATION, then send the
> SELECT_INTERFACE to change the alternate setting. Also remember that
> SELECT_INTERFACE can fail if there is not enough bandwidth for the
> isochronous endpoints in your alternate setting.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
huangjj wrote:
Thanks for your help!
I’m just confused by DDK document about _URB_SELECT_CONFIGURATION.
The comment of _URB_SELECT_CONFIGURATION.Interface says:
“Before the request is sent to the host controller driver, the driver may
select
an alternate setting for one or more of the interfaces contained in this
array
by setting members of the USBD_INTERFACE_INFORMATION structure
for that interface.”
Therefore, I try to select alternate setting 1 for set configure request.
But I don’t see select interface command is sent after set configure command
is sent.
I wonder why DDK has this comment.
I don’t know. It will take someone with knowledge of the USB host
controller internals to answer this. In order for that comment to be
true, the host controller would have to issue SET_INTERFACE requests
after issuing the SET_CONFIGURATION, and like you, I have never seen it
do that.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> I don’t know. It will take someone with knowledge of the USB host
controller internals to answer this. In order for that comment to be
true, the host controller would have to issue SET_INTERFACE requests
after issuing the SET_CONFIGURATION, and like you, I have never seen
it do that.
If a device has Interface Descriptors with multiple alternate interface settings then when the USB host controller driver processes a URB_FUNCTION_SELECT_CONFIGURATION request it should send a Set Interface request to the device after sending a Set Configuration request to the device as part of processing the URB_FUNCTION_SELECT_CONFIGURATION request.
It should send one Set Interface request to the device for each USBD_INTERFACE_INFORMATION contained in the _URB_SELECT_CONFIGURATION if the Interface Descriptor for that interface has multiple alternate interface settings, using the AlternateSetting value contained in each USBD_INTERFACE_INFORMATION.
If this is not the behavior that is observed in a bus trace then maybe there is something odd or not quite correct with the ConfigurationDescriptor that is attached to the _URB_SELECT_CONFIGURATION.
I use isousb sample code of XPDDK to test on Win2000 SP4.
The device contains two interfaces - inerface 0 and interface 1.
Interface 1 contains multiple alternate settings.
I use USBD_ParseConfigurationDescriptorEx like the following
way to prepare the interface list for interface 1.
I can get the pointer to the interface descriptor of alternate setting 1 and
set it in the associated interface list.
After Urb is passed down and completed, I also get all information of
alternate setting 1 successfully.
However, I didn’t see set interface command is sent on USB bus.
// get pointer to interface descriptor with alternate setting 1
interfaceDescriptor =
USBD_ParseConfigurationDescriptorEx(
ConfigurationDescriptor,
ConfigurationDescriptor,
1, // interface number
1, //alt setting 1
-1, // hub class
-1, // subclass, don’t care
-1); // protocol, don’t care
if (interfaceDescriptor)
{
interfaceList->InterfaceDescriptor = interfaceDescriptor;
interfaceList++;
}
…
> If a device has Interface Descriptors with multiple alternate interface
> settings then when the USB host controller driver processes a
> URB_FUNCTION_SELECT_CONFIGURATION request it should send a Set Interface
> request to the device after sending a Set Configuration request to the
> device as part of processing the URB_FUNCTION_SELECT_CONFIGURATION
> request.
>
> It should send one Set Interface request to the device for each
> USBD_INTERFACE_INFORMATION contained in the _URB_SELECT_CONFIGURATION if
> the Interface Descriptor for that interface has multiple alternate
> interface settings, using the AlternateSetting value contained in each
> USBD_INTERFACE_INFORMATION.
>
> If this is not the behavior that is observed in a bus trace then maybe
> there is something odd or not quite correct with the
> ConfigurationDescriptor that is attached to the _URB_SELECT_CONFIGURATION.
>
>
> I use isousb sample code of XPDDK to test on Win2000 SP4.
The device contains two interfaces - inerface 0 and interface 1.
Interface 1 contains multiple alternate settings.
However, I didn’t see set interface command is sent on USB bus.
Two questions:
(1) Is USBCCGP loaded for your multiple interface device, i.e. is your driver FDO attached to a USBCCGP enumerated PDO or to a USBHUB enumerated PDO?
(2) Do you see the same behavior on Windows XP SP2 or Windows Vista?
It appears that the Windows 2000 version of USBCCGP will not check for a non-default AlternateSetting when it processes a URB_FUNCTION_SELECT_CONFIGURATION request while the Windows XP and Windows Vista versions of USBCCGP will check for a non-default AlternateSetting when it processes a URB_FUNCTION_SELECT_CONFIGURATION and issue a URB_FUNCTION_SELECT_INTERFACE request if necessary.
xxxxx@microsoft.com wrote:
It appears that the Windows 2000 version of USBCCGP will not check for a non-default AlternateSetting when it processes a URB_FUNCTION_SELECT_CONFIGURATION request while the Windows XP and Windows Vista versions of USBCCGP will check for a non-default AlternateSetting when it processes a URB_FUNCTION_SELECT_CONFIGURATION and issue a URB_FUNCTION_SELECT_INTERFACE request if necessary.
Ah, now there’s a key tidbit of information: it only sends
SELECT_INTERFACE for interfaces with a non-default alternate setting.
That’s certainly sensible, and it may explain why I’ve never seen it.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>> It appears that the Windows 2000 version of USBCCGP will not check for
> a non-default AlternateSetting when it processes a
> URB_FUNCTION_SELECT_CONFIGURATION request while the Windows XP and
> Windows Vista versions of USBCCGP will check for a non-default
> AlternateSetting when it processes a URB_FUNCTION_SELECT_CONFIGURATION
> and issue a URB_FUNCTION_SELECT_INTERFACE request if necessary.
>
Ah, now there’s a key tidbit of information: it only sends
SELECT_INTERFACE for interfaces with a non-default alternate setting.
That’s certainly sensible, and it may explain why I’ve never seen it.
There is an important distinction here between what USBCCGP does and what USBPORT does. That “key tidbit” only applies to USBCCGP when it receives a URB_FUNCTION_SELECT_CONFIGURATION request passed down to one of its child enumerated PDOs and does not apply to USBPORT.
When USBCCGP initially sends down its own initiated URB_FUNCTION_SELECT_CONFIGURATION request for the entire composite device and that request is received by USBPORT, USBPORT should send a Select Interface request for each interface on the device with multiple alternate interface settings.
My device is an USB video class device.
It uses IAD to describe a single video function that contains two
interfaces.
One is for video control interface and the other is for video stream
interface.
Only one device will appear for this camera device since it’s a single video
function.
Therefore, USBCCGP is not loaded for my device on Windows 2000 SP4.
I didn’t try this on Windows XP and Vista.
…
>>> It appears that the Windows 2000 version of USBCCGP will not check for
>>> a non-default AlternateSetting when it processes a
>>> URB_FUNCTION_SELECT_CONFIGURATION request while the Windows XP and
>>> Windows Vista versions of USBCCGP will check for a non-default
>>> AlternateSetting when it processes a URB_FUNCTION_SELECT_CONFIGURATION
>>> and issue a URB_FUNCTION_SELECT_INTERFACE request if necessary.
>>>
>>
>> Ah, now there’s a key tidbit of information: it only sends
>> SELECT_INTERFACE for interfaces with a non-default alternate setting.
>> That’s certainly sensible, and it may explain why I’ve never seen it.
>>
>
> There is an important distinction here between what USBCCGP does and what
> USBPORT does. That “key tidbit” only applies to USBCCGP when it receives
> a URB_FUNCTION_SELECT_CONFIGURATION request passed down to one of its
> child enumerated PDOs and does not apply to USBPORT.
>
> When USBCCGP initially sends down its own initiated
> URB_FUNCTION_SELECT_CONFIGURATION request for the entire composite device
> and that request is received by USBPORT, USBPORT should send a Select
> Interface request for each interface on the device with multiple alternate
> interface settings.
>
>
> My device is an USB video class device. It uses IAD to describe a
single video function that contains two interfaces. One is for video
control interface and the other is for video stream interface. Only
one device will appear for this camera device since it’s a single
video function. Therefore, USBCCGP is not loaded for my device on
Windows 2000 SP4.
I didn’t try this on Windows XP and Vista.
I don’t know why you don’t see a Select Interface request. As far as I can tell you should see one, but there are two many variables involved to be sure why you don’t see this without looking at this in the debugger.
You could also try this on Windows XP SP2 or Windows Vista for comparison. Perhaps there is a problem with this somewhere in Windows 2000 SP4 that was fixed in Windows XP SP2 or Windows Vista.