Prev: OEMTextOut glyph position problem
Next: Problem with Devmode corruptor test
From: KMDF_FW on 25 Apr 2007 20:24
Tim:

Hi, thanks for the detailed explaination. I was able to achieve what I need
to do
with the driver by sending the data as part of a vendor command.

AT

"Tim Roberts" wrote:

> KMDF_FW <KMDFFW(a)discussions.microsoft.com> wrote:
> >
> >Here is another thing that I need to check with you regarding USB device.
> >To verify the end point of the USB that I works on, I used the USB view from
> >sdk yesterday, and it's shown that it's an IN pipe of INT type. The part of
> >info that surprise me is the wMaxPacketSize of the device is 0. Does that
> >mean the pipe can not be used for writing data? And there is only one
> >endpoint/pipe for this device.
>
> This means you are looking at "alternate setting zero". Interrupt and
> isochronous pipes cause bandwidth to be reserved. If there isn't enough
> bandwidth available, the pipe is not allowed to become active. Because of
> that, the default interface ("alternate setting zero") is required to have
> wMaxPacketSize = 0, so it can always be activated.
>
> Your device will also have other alternate setttings that have
> wMaxPacketsize > 0. You just have to choose one of those alternate
> settings (using USB_FUNCTION_SELECT_INTERFACE) before you start reading
> data.
>
> However, I thought you said you wanted to SEND data? USB endpoints go in
> one direction only. An "IN" pipe transfers from the device to the host. To
> send data, you need to use an "OUT" pipe.
> --
> Tim Roberts, timr(a)probo.com
> Providenza & Boekelheide, Inc.
>
From: Maxim S. Shatskih on 26 Apr 2007 06:57
> Meanwhile, I am wondering whether there is a corresponding kernel API
> like Sleep() from user mode?

KeDelayExecutionThread

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim(a)storagecraft.com
http://www.storagecraft.com

First  |  Prev  | 
Pages: 1 2 3
Prev: OEMTextOut glyph position problem
Next: Problem with Devmode corruptor test