Problem in installing HID mini driver...

NTDEV
1

Hello all,

We are developing a HID mini driver and a USB client driver for a HID USB
device. I am using Walter Oney’s WDM book and also the DDK’s “hidgame”
sample.

My questions are:

to which class does this device on system belong?
how to install both USB client driver and the HID mini driver?
how does the HID class driver gets loaded and how the mini driver gets added to the driver stack?
can anyone explain the coupling between HID stack and the USB stack?

Any pointers and suggestions are appriciated.

Thanks in advance.

Pramodh

2

> > to which class does this device on system belong?

Whatever you specify in the Inf file.

> how to install both USB client driver and the HID mini driver?

Do you want them to be separate .sys files? Need more info to answer it.

> how does the HID class driver gets loaded and how the mini driver gets
added to the driver stack?

Again, are they separate drivers? Generally, your function driver is the
mini driver and it sits below the hidclass driver. The hid mini, just gets
loaded like any other driver, but in driverentry you register with the hid
class. Hidclass sticks it self above your driver in the stack.

> can anyone explain the coupling between HID stack and the USB stack?

There are a couple of implementation choices, but basically the USB makes a
child device for your Usb function driver ( your above the usb
driver). When you register with hid class, it inserts itself above the
function driver.

-Justin

At 12:54 AM 10/9/2002, you wrote:

Hello all,

We are developing a HID mini driver and a USB client driver for a HID USB
device. I am using Walter Oney’s WDM book and also the DDK’s “hidgame”
sample.

My questions are:
> to which class does this device on system belong?
> how to install both USB client driver and the HID mini driver?
> how does the HID class driver gets loaded and how the mini driver gets
added to the driver stack?
> can anyone explain the coupling between HID stack and the USB stack?

Any pointers and suggestions are appriciated.

Thanks in advance.

Pramodh

You are currently subscribed to ntdev as: zeppelin@io.com
To unsubscribe send a blank email to %%email.unsub%%

3

“A.G.Pramodh” wrote:

My questions are:
> to which class does this device on system belong?
> how to install both USB client driver and the HID mini driver?
> how does the HID class driver gets loaded and how the mini driver gets added to the driver stack?
> can anyone explain the coupling between HID stack and the USB stack?

I suggest making it a HID class device. Use a single driver, too –
there’s no particular need to separate the HID minidriver functionality
from the USB client driver. HIDCLASS will get loaded implicitly because
your DriverEntry routine calls a routine (HidRegisterMinidriver) that
HIDCLASS exports. HIDCLASS then issues a number of internal control
requests that your minidriver services. The “coupling” between stacks
happens as a result of the URBs you send down the USB stack to implement
these control requests.

I hear tell that, if there were a beta test program involving some
hypothethical future version of Windows and if there were to be a DDK
that was part of that beta program, there might be a new sample of a
virtual HID device that would be useful to you. But of course various
NDAs make it impossible for me to speculate on the existence or
nonexistence of any such operating system, DDK, or sample. If you get my
drift.

BTW, if you have a USB device, why do you want to write a minidriver in
the first place? HIDUSB will handle a standard HID device just fine.

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com

4

Hello,

Thanks walter.

My proposed solution looks somewhat like this:

Kernel mode

Other upper HID drivers (wrappers, clients)
|
|
HID class driver
|
|
HID mini driver*
|
|
Bluetooth driver*
|
|
USB client driver*
|
|
system USB drivers (usbd.sys)
|
|
USB hardware with talks to the HID Bluetooth devices

*The three drivers, HID mini driver, Bluetooth driver and the USB client
driver are developed independently and their interfaces are well defined.

Since I have a Bluetooth driver between USB client driver and the HID
class driver, I can’t reuse the hidusb.sys minidriver.
That why I ended up in developing the HID mini driver.

Now I am facing the problem in deciding the load order for these drivers.
I want to test the HID mini driver and the USB client driver.

How can I load these 2 drivers? Can I use a common inf file?
Can u please give me the prototype of the inf which enables loading such
drivers?

I tried to use device CoInstaller section in the inf file of USB client
driver to load the HID class and mini driver. The USB client driver gets
loaded, but not able to load the class and mini driver.

I hope the info provided above is ok for you to help me.

Thanks again for the respones.

Waiting for u help.

Pramodh.

5

“A.G.Pramodh” wrote:

My proposed solution looks somewhat like this:

Here’s a slightly different picture that may clarify the relationships.
I’m afraid that line wrapping will obscure the aesthetics of this
picture, so you may want to to edit what you see in your news reader.

collection drivers
|
mini-driver (PDO - - - - mini-driver (FDO)
HIDCLASS hat) HIDCLASS hat)
|
bluetooth driver
|
USB client drier
|
USBHUB (PDO hat) - - - USBHUB (FDO hat)
|
(etc.)

Anyhow, your mini–driver and HIDCLASS really belong in the same box
since the two of them together add up to a multifunction driver. Wearing
its PDO, or bus-driver hat, this driver creates PDOs for the top-level
collections in the report descriptor and calls the dispatch routine for
IRP_MJ_INTERNAL_DEVICE_CONTROL. This call looks like a regular call to
an IRP dispatch routine, but it’s really a direct subroutine call
between components of a single, two-module, driver.

Anyhow, your job in your minidriver is to implement those internal
control requests according to what you say is the well-defined interface
to your bluetooth driver. Given the layering you showed, you shouldn’t
need to talk directly to any other driver in the stack.

As far as installation goes, the bluetooth and USB client drivers would
be “device lower filter” drivers. That is, you would install them along
with your minidriver (in the same INF file), define services for them,
and define a LowerFilters value in the driver key. Grep the DDK sample
directory and the \Windows\INF directory for the words “LowerFilters”
and “UpperFilters” and you’ll probably find a few examples of something
similar.

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com