locked
Selecting a USB Configuration RRS feed

  • Question

  • I am looking into implementing Select Configuration request  of USB device in  a KMDF bus driver that simulates USB devices. I have a couple of questions. Hope the questions make sense:

    1. When the SelectConfiguration request( _URB_SELECT_COFIGURATION structure) arrives, it has a USBD_INTERFACE_INFORMATION  member. Is this to be filled by the KMDF driver's Select Configuration callback implementation?

    2. Should the callback fill the details of all the  interfaces/endpoints under the configuration? Does it matter if we miss one or more interfaces? Will the simulation still work?

    3. In general, is it possible for a device have an interface without endpoints? Are there such devices?

    4. Normally when creating the PDO of a composite device, the bus driver is given the class, subclass, protocol values that are part of the Device Descriptor. Is this the expected method of USB device simulation using bus driver?

    5. Is it possible to simulate a USB device by giving the class, subclass, protocol values of one of the interfaces, if we need only that interface to load?

    6. Is there any special significance in the Miscellaneous class code(EFh)?  Is this similar to giving class, subclass, protocol values as zero in the device descriptor of a composite device?

    Wednesday, July 13, 2016 7:15 PM

Answers

  • 1. The documentation tells you this, and the structure declarations in the header file are quite good about saying what is input and what is output.  The client driver has to fill in the USBD_INTERFACE_INFORMATION array, based on information it read from the configuration descriptor.  Note that each USBD_INTERFACE_INFORMATION structure contains a USB_PIPE_INFORMATION array, so it's a complicated structure.  It is the host controller's responsibility to fill in the pipe handles.  That's what the client driver will use to refer to the pipes in the future.

    Remember that SELECT_CONFIGURATION also does a SELECT_INTERFACE on all of the interfaces.  If some of the interfaces have interrupt or isochronous endpoints, you have to start the periodic processing.

    2. "Does it matter is we miss one or more interfaces"???  You can't possibly be serious with that question.  If the application configures three interfaces, then by God it has the right to use all three interfaces.

    3. Yes, it's possible.  It's extremely common for a device with isochronous endpoints to define the base (alternate setting = 0) configuration with no endpoints.  It then selects another alternate setting once it knows the bandwidth needs.

    4. This is a different level of responsibility.  The host controller driver manages the SelectConfiguration request, but it is the USB hub driver that creates the PDOs.  It creates one hardware ID with the VID and PID, and another hardware ID with the CLASS_xx string.

    5. Again, I'm not sure what you mean.  The USB hub driver will fetch the configuration descriptor, enumerate the interfaces, and extract the information from the interfaces to create PDOs and hardware IDs.  If you want to limit the complexity, you can certainly rewrite the configuration descriptor on the way through.

    6. There is no special significance.  It will get a USB\CLASS_EF hardware ID, and by default there is no driver for that class.  That's all.


    Tim Roberts, Driver MVP Providenza & Boekelheide, Inc.

    Thursday, July 21, 2016 7:42 AM

All replies

  • are you using a framework to help with the handling of URB processing and enumeration? if yes, is it UCX or something else?

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, July 13, 2016 10:26 PM
  • Thanks Doron. Yes, I am using framework help. Its is not UCX. I am handling the URB_FUNCTION_SELECT_CONFIGURATION URB in the InternalDeviceControl callback of the bus driver. 



    • Edited by its_me_here Thursday, July 14, 2016 5:31 AM
    Thursday, July 14, 2016 5:30 AM
  • please name the framework. if it is a Microsoft supplied one, you can get help here. if its somebody else's framework, go ask that vendor for help as it is their code

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, July 14, 2016 7:24 AM
  • I am using the KMDF framework. In my KMDF bus driver the device descriptor and configuration descriptor requests are working fine. But when FUNCTION_SELECT_CONFIGURATION arrives in the bus driver internal device control , I have obtained the Class, Subclass, Protocol and Number of pipes and Interface handle from the incoming   FUNCTION_SELECT_CONFIGURATION  URB as below: The values are found to be zero though the device's actual values are not zero( some values verified with USBView).

    NTSTATUS SelectConfiguration(PPDO_DEVICE_DATA PdoData, struct _URB_SELECT_CONFIGURATION * req)
    {
    	
    	USBD_INTERFACE_INFORMATION *Interface = &req->Interface;
    	//Print the class , subclass, protocol, interface handle values etc.
    
    
    }
    What could be wrong here?. I dumped and verified the configuration descriptors passed to the usb stack before the arrival of select configuration URB and the values are correct.

    Tuesday, July 19, 2016 1:23 PM
  • no idea. kmdf doesn't parse these buffers when the are received. you have to debug yourself

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, July 19, 2016 3:40 PM
  • 1. The documentation tells you this, and the structure declarations in the header file are quite good about saying what is input and what is output.  The client driver has to fill in the USBD_INTERFACE_INFORMATION array, based on information it read from the configuration descriptor.  Note that each USBD_INTERFACE_INFORMATION structure contains a USB_PIPE_INFORMATION array, so it's a complicated structure.  It is the host controller's responsibility to fill in the pipe handles.  That's what the client driver will use to refer to the pipes in the future.

    Remember that SELECT_CONFIGURATION also does a SELECT_INTERFACE on all of the interfaces.  If some of the interfaces have interrupt or isochronous endpoints, you have to start the periodic processing.

    2. "Does it matter is we miss one or more interfaces"???  You can't possibly be serious with that question.  If the application configures three interfaces, then by God it has the right to use all three interfaces.

    3. Yes, it's possible.  It's extremely common for a device with isochronous endpoints to define the base (alternate setting = 0) configuration with no endpoints.  It then selects another alternate setting once it knows the bandwidth needs.

    4. This is a different level of responsibility.  The host controller driver manages the SelectConfiguration request, but it is the USB hub driver that creates the PDOs.  It creates one hardware ID with the VID and PID, and another hardware ID with the CLASS_xx string.

    5. Again, I'm not sure what you mean.  The USB hub driver will fetch the configuration descriptor, enumerate the interfaces, and extract the information from the interfaces to create PDOs and hardware IDs.  If you want to limit the complexity, you can certainly rewrite the configuration descriptor on the way through.

    6. There is no special significance.  It will get a USB\CLASS_EF hardware ID, and by default there is no driver for that class.  That's all.


    Tim Roberts, Driver MVP Providenza & Boekelheide, Inc.

    Thursday, July 21, 2016 7:42 AM
  • Thank you Tim !! That was really well-explained. Though the configuration descriptors are correctly input in configuration descriptor request, when select configuration request comes, the values in the URB structure are zero except for number of interfaces. I guess these values should be filled in FUNCTION_SELECT_CONFIGURATION  when configuration descriptor request was  processed so that select configuration is aware of these values, rt?  My device is an audio device with 3 interfaces and 1 alternate interface.
    Monday, July 25, 2016 10:04 AM