WinUSB - WinUsb_ControlTransfer ignoring Index field?
ryan01701
on USB. I can successfully open a handle to it via the standard methods
(CreateFile, WinUsb_Initialize) and communicate via control transfers with
interface 0.
However, I want to send a request to interface 2. I initialize my
WINUSB_SETUP_PACKET as desired, with the Index field set to 2. But on my USB
analyzer, when I see the packet go out, the Index field is 0.
Am I missing a call in to the driver to allow or otherwise enable interface
#2? What would cause the Index field to change value inside the driver call?
Thanks,
--
Ryan
Tim Roberts
>
>I have a device that presents the standard Bluetooth HCI controller interface
>on USB. I can successfully open a handle to it via the standard methods
>(CreateFile, WinUsb_Initialize) and communicate via control transfers with
>interface 0.
>
>However, I want to send a request to interface 2.
Is your driver's INF matching the entire composite device
(VID_xxxx&PID_xxxx), or are you only matching interface 0
(VID_xxxx&PID_xxxx&MI_00)?
>I initialize my
>WINUSB_SETUP_PACKET as desired, with the Index field set to 2. But on my USB
>analyzer, when I see the packet go out, the Index field is 0.
If you're only matching interface 0, it's possible that the default
composite driver is overriding the index number, since interface 2 belongs
to someone else. I'd be surprised at that but it's not impossible.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Maxim S. Shatskih
> on USB.
How can you use WinUSB for it? Am I wrong that the controller must be plugged to MS's kernel-mode Bluetooth stack?
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
ryan01701
> ryan01701 <ryan...@discussions.microsoft.com> wrote:
> >
> >I have a device that presents the standard Bluetooth HCI controller interface
> >on USB. I can successfully open a handle to it via the standard methods
> >(CreateFile, WinUsb_Initialize) and communicate via control transfers with
> >interface 0.
> >
> >However, I want to send a request to interface 2.
>
> Is your driver's INF matching the entire composite device
> (VID_xxxx&PID_xxxx), or are you only matching interface 0
> (VID_xxxx&PID_xxxx&MI_00)?
>
It matches the entire device, using the first format you list.
[Manufacturer]
%ProviderName% = MyDevice_WinUSB,NTx86,NTamd64,NTia64
[MyDevice_WinUSB.NTx86]
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_xxxx&PID_0001
[MyDevice_WinUSB.NTamd64]
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_xxxx&PID_0001
[MyDevice_WinUSB.NTia64]
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_xxxx&PID_0001
--
Ryan
ryan01701
> >I have a device that presents the standard Bluetooth HCI controller interface
> > on USB.
>
> How can you use WinUSB for it? Am I wrong that the controller must be plugged to MS's kernel-mode Bluetooth stack?
I'm interested in interfacing with it as a "raw" device, so WinUSB is
suitable for my needs. I don't want or need to use any higher level
Bluetooth functionality from the operating system.
--
Ryan
Philip Ries [MSFT]
WinUsb_GetAssociatedInterface to get an interface handle, with which you
would then call WinUsb_ControlTransfer.
http://msdn.microsoft.com/en-us/library/ff540245(VS.85).aspx
Tim Roberts
>
>Just taking a glance at the docs, you could look into calling
>WinUsb_GetAssociatedInterface to get an interface handle, with which you
>would then call WinUsb_ControlTransfer.
If that works, that would be both quite unexpected, and contrary to the
documentation. The WinUsb_ControlTransfer doc clearly says to use the
default interface for the device.
http://msdn.microsoft.com/en-us/library/ff540219.aspx
I guess we need to do some disassembling to find out for sure.
WinUsb_ControlTransfer should NOT be rewriting the fields in the control
packet.
Tim Roberts
>WinUsb_GetAssociatedInterface to get an interface handle, with which you
>would then call WinUsb_ControlTransfer.
Well, disassembling winusb.dll didn't help. WinUsb_ControlTransfer does
nothing other than bundle the parameters up into a structure and pass it
via DeviceIoControl to winusb.sys.
ryan01701
> "Philip Ries [MSFT]" <phr...@microsoft.com> wrote:
> >
> >Just taking a glance at the docs, you could look into calling
> >WinUsb_GetAssociatedInterface to get an interface handle, with which you
> >would then call WinUsb_ControlTransfer.
>
> Well, disassembling winusb.dll didn't help. WinUsb_ControlTransfer does
> nothing other than bundle the parameters up into a structure and pass it
> via DeviceIoControl to winusb.sys.
I tried re-implementing my design using the Windows port of libusb-1.0.0
(http://www.libusb.org/wiki/windows_backend) and it suffers from the same
problem. Interestingly, the exact same code works on a Mac (linking to the
Mac version of the libusb lib, of course), so I'm pretty sure it's not an
issue with how I am using that library. It definitely seems to be something
strange with WinUSB.
--
Ryan
Philip Ries [MSFT]
If the WinUsb_ControlTransfer handling does require the appropriate
interface handle to be specified, then I see the issue that Tim pointed
out in the documentation of WinUsb_ControlTransfer's InterfaceHandle
parameter.
Philip
ryan01701
> Please give WinUsb_GetAssociatedInterface a try, and let us know the result.
>
> If the WinUsb_ControlTransfer handling does require the appropriate
> interface handle to be specified, then I see the issue that Tim pointed
> out in the documentation of WinUsb_ControlTransfer's InterfaceHandle
> parameter.
When I try calling this function with AssociatedInterfaceIndex set to 2 (the
value of the bInterfaceNumber field of the interface descriptor in which I'm
interested), it fails and GetLastError() reports ERROR_NO_MORE_ITEMS.
Here are the configuration and interface descriptors of interest for the
device as displayed by UVCView in the WinDDK toolkit:
===>Configuration Descriptor<===
bLength: 0x09
bDescriptorType: 0x02
wTotalLength: 0x00C1 -> Validated
bNumInterfaces: 0x03
bConfigurationValue: 0x01
iConfiguration: 0x00
bmAttributes: 0xC0 -> Bus Powered
MaxPower: 0x00 = 0 mA
===>Interface Descriptor<===
bLength: 0x09
bDescriptorType: 0x04
bInterfaceNumber: 0x02
bAlternateSetting: 0x00
bNumEndpoints: 0x00
bInterfaceClass: 0xFE -> This is an Application Specific
USB Device Interface Class
-> This is a Device Firmware Application Specific USB Device Interface Class
bInterfaceSubClass: 0x01
bInterfaceProtocol: 0x00
CAUTION: This may be an invalid bInterfaceProtocol
iInterface: 0x00
===>Descriptor Hex Dump<===
bLength: 0x07
bDescriptorType: 0x21
07 21 07 88 13 FF 03
--
Ryan
Philip Ries [MSFT]
"The first associated interface is the interface that immediately
follows the interface whose handle the WinUsb_Initialize routine retrieves."
"AssociatedInterfaceIndex [in]
An index that specifies the associated interface to retrieve. A value of
0 indicates the first associated interface, a value of 1 indicates the
second associated interface, and so on."
Use a value of 1 to specify the interface descriptor at index 2.
(Again, that is my own reading and I have not tried this.)
ryan01701
> WinUsb_GetAssociatedInterface:
>
> "The first associated interface is the interface that immediately
> follows the interface whose handle the WinUsb_Initialize routine retrieves."
>
> "AssociatedInterfaceIndex [in]
> An index that specifies the associated interface to retrieve. A value of
> 0 indicates the first associated interface, a value of 1 indicates the
> second associated interface, and so on."
>
> Use a value of 1 to specify the interface descriptor at index 2.
> (Again, that is my own reading and I have not tried this.)
I suppose I should try reading the documentation =) This works as expected;
the wIndex field of my control transfer is correct after calling
GetAssociatedInterface and using that handle for calls into WinUsb.dll.
Thanks very much for the help. Can the API documentation be improved to
indicate that this ste[ is necessary in order to talk to other interfaces?
The libusb Windows backend team would probably like to know this as well.
--
Ryan