I noticed today that WdfUsbTargetDeviceGetInterface() expects a zero-based index, and not the value of bInterfaceNumber when you are calling it.
The doc says, “This index value might not be the same as the interface number that the USB specification defines,” which isn’t totally clear.
Further, when I debugged it, judging by the function names, it looks like KMDF just goes and unmaps the index you provide to the true interface number anyway when you call the function.
Is there a reason for this? It’s complicated what I’m trying to do because now I have to maintain my own mapping as well in my driver…which is just thrown away in the end, really.
xxxxx@gmail.com wrote:
I noticed today that WdfUsbTargetDeviceGetInterface() expects a zero-based index, and not the value of bInterfaceNumber when you are calling it.
The doc says, “This index value might not be the same as the interface number that the USB specification defines,” which isn’t totally clear.
Further, when I debugged it, judging by the function names, it looks like KMDF just goes and unmaps the index you provide to the true interface number anyway when you call the function.
Is there a reason for this? It’s complicated what I’m trying to do because now I have to maintain my own mapping as well in my driver…which is just thrown away in the end, really.
Tradition. WDM USB drivers have always been this way. The interface
data structures are initialized from the configuration descriptor, so
the numbers are in sequential order as they appear in the descriptor.
The interface number doesn’t have any meaning outside of the device, so
there is no particular reason to force I/O subsystem to do the lookup.
The index is just as good as the interface number.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
It was done for 2 reasons.
- The iteration APIs in KMDF and esp in USB related objects all use a zero based index so it is consistent across objects (and is consistent with WinUSB as well)
- The zero based index is a complete range. It has a definitive end. If you used the bInterfaceNumber, there can easily be holes and the only way to find the holes is to know them apriori or parse the config descriptor itself.
Consider a class (or any generic driver written to a class spec) driver, it doesn’t care about the interface number itself, rather the settings on the interface is important, so it just wants to iterate over the interfaces one by one, irrespective of the bInterfaceNumber.
d