Prev: Printer driver and DEVMODE confusion
Next: Security warning when upgrading a signed driver
From: Bivar on 9 Dec 2009 11:31
I understand and have executed the SetupDIGetClassDevs-
>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*.
From: Doron Holan [MSFT] on 10 Dec 2009 18:02
the device path will be for a particular function on the composite device,
not the entire composite device.

d

--

This posting is provided "AS IS" with no warranties, and confers no rights.


"Bivar" <gbarbehenn(a)linear.com> wrote in message
news:dcb4f1ba-2b0c-4191-8204-47e14af7b8a5(a)j4g2000yqe.googlegroups.com...
> I understand and have executed the SetupDIGetClassDevs-
>>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*.

From: Tim Roberts on 12 Dec 2009 00:00
"Doron Holan [MSFT]" <doron.holan(a)online.microsoft.com> wrote:
>
>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, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Tim Roberts on 12 Dec 2009 00:05
Bivar <gbarbehenn(a)linear.com> wrote:
>
>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?
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Doron Holan [MSFT] on 16 Dec 2009 18:30
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.


"Tim Roberts" <timr(a)probo.com> wrote in message
news:7p86i598sgfm3bj3pn112t2jrkghm9jdvq(a)4ax.com...
> "Doron Holan [MSFT]" <doron.holan(a)online.microsoft.com> wrote:
>>
>>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, timr(a)probo.com
> Providenza & Boekelheide, Inc.

 | 
Pages: 1
Prev: Printer driver and DEVMODE confusion
Next: Security warning when upgrading a signed driver