extending class driver
From: valentin tihomirov (valentin_NOSPAM_NOWORMS_at_abelectron.com)
Date: 07/05/04
- Next message: Sten Westerback: "Re: Problems with "Safely Remove Hardware""
- Previous message: William DePalo [MVP VC++]: "Re: Global Hooks"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 5 Jul 2004 06:25:12 +0300
Hello,
I have a usb device of a HID class. The class driver does not support one
standard request (Get_Input_Report) until WinXP. Since my device supports it
I want to make use of it. What is a typical solution
-- sending request from app directly to the underlying USB driver?
-- a custom driver above hid driver?
-- an upper/lower filter of class driver?
-- any replacement/filter of the minidirver?
-- anything else?
Here is an article showing a custom camera driver sitting above video camera
class driver:
http://www.microsoft.com/msj/0199/windowsdriver/windowsdriver.aspx
Furthermore, the article even mentiones that in the case an underlying
intermediate driver(s) (in our case these are hidclass and usbhid drivers)
cannot understand a request, it should forward it downto the bus driver.
This resolves my major consern - how can additional request/method be
introduced in some interface if underlying drivers are not aware of it and
refuse processing it? Before this information, I was thinking that we must
commnicate directly to device on the bus (whether creating a new connection
or hacking into this one opened by the application) bypassing the
intermediate driver(s) in order to make custom IO with device. Fortunately,
there is not need to find underlying device object from the stack to
communicate directly when we know that our custom request unknown to
intermediate drivers will eventually reach bus driver. Is it guaranteed that
unknown requests will be passes through by intermediate drivers? How do I
know which request codes are not known to the intermediate drivers, what if
all codes are used?
So far so good, but then I've encountered the 13th chapter of famous W.
Oney's book:
http://www.microsoft.com/mspress/books/sampchap/6262.asp#SampleChapter
He raises one more opportunuty to adding the desired functionality into the
driver. He states that both ReadFile and HidD_GetInputReport are implemented
by IOCTL_HIDD_READ_REPORT minidriver's workhorse. ReadFile and
HidD_GetInputReport are high-level functions known to hid class driver and
application. Today, I use ReadFile in win200 application. The problem is
that the function is blocking until only when device sends them (there are
long periods when device is silent). The HidD_GetInputReport function forces
device to send data immediately without delay. But it is new in Win XP.
The vital info that the demanded HidD_GetInputReport function is implemented
by minidriver gives me a hope that I can accomplish without writing any
driver. However, I have no ideas about how to organize direct communication
between application and the minidriver bypassing the class driver? I'm
scared by these words:
"These I/O control (IOCTL) operations are also the way Microsoft would
prefer you perform out-of-band communication between an application and a
HID minidriver. Bear in mind that HIDCLASS doesn't allow anyone to open a
handle to the device itself (handles may be opened only to top-level
collections) and fails any nonstandard control operations that it happens to
receive. Without resorting to sleazy methods, as to which I won't say
anything, there is actually no other way for an application and a HIDCLASS
minidriver to communicate."
Does this means that HIDCLASS will reject any requests it cannot understand
making direct communication with minidriver and usb driver impossible?
Furthermore, the author states that even with a true HID-CLASS USB device
custom minidrivers may be written to replace HIDUSB.SYS to support custom
functionality.
The hidclass driver operates at the top of the stack. As far as I can
understand, usbhid.sys minidriver translates hid commants into USB requests
and passes them to USB driver.
In fact, the Get_Input_Report request that I want to add to the HIDCLASS
driver is not my custom device specific; it is a part of USB HID device
class specification and must be supported by the driver in releases
preceding WinXP as well. Thus, I wonder, may be somebody has already has a
version of such extended hidclass driver? Otherwise, I could do it and
publish.
Finally, if I'll succeed with the driver, can I use it installing without
.inf file? It would be convenient for a client to load the driver if he/she
decides that the function is needed in his/her program.
I know this should be possible employing ServiceManager; "net start" seems
is able of doing his job without requiring any .inf files as well. But I
cannot find any official documentation on the feature.
If something is expressed unclearly, please let me know.
- Next message: Sten Westerback: "Re: Problems with "Safely Remove Hardware""
- Previous message: William DePalo [MVP VC++]: "Re: Global Hooks"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
