Prev: Failed to modify existing service
Next: memory descriptor list
From: Tim Roberts on 16 Jun 2010 00:50
"Philip Ries [MSFT]" <phries(a)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.

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, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Tim Roberts on 16 Jun 2010 00:53
"Philip Ries [MSFT]" <phries(a)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.
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: ryan01701 on 17 Jun 2010 08:03
"Tim Roberts" wrote:

> "Philip Ries [MSFT]" <phries(a)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

From: Philip Ries [MSFT] on 18 Jun 2010 16:18
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]" <phries(a)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.
>
From: ryan01701 on 21 Jun 2010 13:22
"Philip Ries [MSFT]" wrote:

> 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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Failed to modify existing service
Next: memory descriptor list