WinUSB device path
Bivar
>SetupDiGetDeviceInterfaceDetail->get SP_DEVICE_INTERFACE_DETAIL_DATA
structure to retrieve the DevicePath.
Suppose I have a USB device that for a given configuration exposes the
3 interfaces of a composite device. Because this is a composite
device, the endpoints exposed by the 3 interfaces need to be unique,
so Interface 1= endpoints 2 & 3, Interface 2=endpoints 4 & 5, and
Interface 3=endpoints 6 & 7.
So, when I obtain the exalted DevicePath, with the procedure in
paragraph 1, does it give me the DevicePath to the entire USB
composite device or one of (presumably the first) the interfaces? If
the DevicePath is to the entire device, do I access interface 3 by
just accessing endpoints 6 & 7? If it returns the DevicePath for a
particular endpoint, can I then obtain the DevicePaths for the
remaining two interfaces by iterating the
SetupDiGetDeviceInterfaceDetail and then Createfile->
Winusb_Initilialize for *each* of them, to get 3 USB handles, one for
each interface?
The PipeID is charmingly described by MS as having 7 bits of address
and one bit of Read/Write, but not which bits are which. The USB 2.0
specification defines the endpoint address as b[3..0] are the endpoint
number, b[6..4] are reserved, and b[7] is the Read/Write bit. How
does the PipeID map to the USB 2.0 specification?
And does Winusb compare the requested PipeID to the Devices advertised
endpoints to ensure that the requested PipeID is valid? If not the
device will have to check incoming endpoint requests for endpoint
number, direction and byte count, and on mismatch STALL the requested
endpoint. Since most devices only have hardware support for a limited
number of endpoints (7 or 8), there is no hardware support to STALL a
non-existent endpoint, *something that is very non trivial to do in
firmware*.
Doron Holan [MSFT]
not the entire composite device.
d
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Bivar" <gbarb...@linear.com> wrote in message
news:dcb4f1ba-2b0c-4191...@j4g2000yqe.googlegroups.com...
Tim Roberts
>
>the device path will be for a particular function on the composite device,
>not the entire composite device.
Isn't that only going to happen if the INF file matches a specific
interface, like this?
USB\VID_1234&PID_5678&MI_01
If the INF file matches the composite device:
USB\VID_1234&PID_5678
then WinUSB will have access to all 3 interfaces. I don't know how WinUSB
reacts in that case -- I don't see a select interface call.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts
>
>The PipeID is charmingly described by MS as having 7 bits of address
>and one bit of Read/Write, but not which bits are which. The USB 2.0
>specification defines the endpoint address as b[3..0] are the endpoint
>number, b[6..4] are reserved, and b[7] is the Read/Write bit. How
>does the PipeID map to the USB 2.0 specification?
Pipe numbering is essentially universal in the USB world. Output pipes are
numbered 0x01 to 0x0f, input pipes are numbered 0x81 to 0x8f. The whole
"endpoint address" thing is a bit of a misnomer; there is absolutely no
relationship between endpoint 0x01 and 0x81.
>And does Winusb compare the requested PipeID to the Devices advertised
>endpoints to ensure that the requested PipeID is valid?
Yes. WinUSB has to convert your request into a URB to send to the USB
stack, and URBs use "pipe handles", which are only created when the
interface is selected. Pipe handles are only created for existing pipes.
There's no way to send an undefined pipe number to the host controller
driver.
>If not the
>device will have to check incoming endpoint requests for endpoint
>number, direction and byte count, and on mismatch STALL the requested
>endpoint. Since most devices only have hardware support for a limited
>number of endpoints (7 or 8), there is no hardware support to STALL a
>non-existent endpoint, *something that is very non trivial to do in
>firmware*.
Well, the device should be doing this anyway. It's possible that the USB
compliance tests check this. What device are you working with?
Doron Holan [MSFT]
will not really let you address each functional interface in the way you
probably want it to
d
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Tim Roberts" <ti...@probo.com> wrote in message
news:7p86i598sgfm3bj3p...@4ax.com...
petebatard
But then, if you use multiple infs with MI_## numbers (with the same class GUID), how is WinUsb_GetAssociatedInterface supposed to work?
Shouldn't each interface be seen as an independent winusb device then, each with a single interface only?
In short, my question is, what is needed in terms of driver installation, for WinUsb_GetAssociatedInterface to work?
/Pete
Doron Holan [MSFT] wrote:
exactly, winusb can be installed on the top level composite component but
16-Dec-09
exactly, winusb can be installed on the top level composite component but it
will not really let you address each functional interface in the way you
probably want it to
d
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Previous Posts In This Thread:
Submitted via EggHeadCafe - Software Developer Portal of Choice
C# .NET Windows Task Scheduler
http://www.eggheadcafe.com/tutorials/aspnet/9f75423c-4849-4866-ad48-8fbd2ed2ed88/c-net-windows-task-sche.aspx
Doron Holan [MSFT]
work if you replace winusb instead of usbccgp on the top level parent node.
why not install it this way and test it out for yourself?
d
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Pete Batard" wrote in message news:2009121710...@gmail.com...