WinUSB - WinUsb_ControlTransfer ignoring Index field?

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. 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

ryan01701 <> 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)?

>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,
Providenza & Boekelheide, Inc.

>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?

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com

"Maxim S. Shatskih" wrote:

> >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

"Tim Roberts" wrote:

> ryan01701 <> 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

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.

http://msdn.microsoft.com/en-us/libr...45(VS.85).aspx

ryan01701 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. 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,
>

"Philip Ries [MSFT]" <> 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.

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,
Providenza & Boekelheide, Inc.

"Philip Ries [MSFT]" <> 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.
--
Tim Roberts,
Providenza & Boekelheide, Inc.

"Tim Roberts" wrote:

> "Philip Ries [MSFT]" <> 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

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.

Philip

ryan01701 wrote:
> "Tim Roberts" wrote:
>
>> "Philip Ries [MSFT]" <> 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.
>