Can you WHQL a HID minidriver?

[Ray Trent]

I've got a ... charming ... customer that wants us to build a front panel
keypad, but they don't want to use USB... no, that would be too easy .
For "cost" reasons, they want us to make it a serial device and write a HID
minidriver for it. No worries, I'm working on them about that...

I have a question about such a device: Could it be WHQL'd? I'm not 100% sure
how a HID minidriver could be installed INF-only in such a case, and I
haven't looked into whether we can needs/includes hidparse and hidclass
rather than copying them as is done in the sample's INF, among other things.
I suppose I could come up with a serial PnP ID and have serenum enumerate
it... bleah.

Anyway, even assuming I can solve that problem (suggestions appreciated), is
there a WHQL category that could encompass a HID minidriver of this nature
(other than the code coverage beta, that is)? If such exists, I'm presuming
it would non-Self Test and thus require sending MS devices (and a check with
more zeros , is that correct?

Not being able to sign the driver, and therefore not being able to
silent-install it, could (not especially regrettably prevent us from
using this approach.

 

[Doron Holan [MS]]

Lots of pens for tablet PCs use a hid minidriver that talks to a serial
device and not usb. i don't the particular rules, but there is precedent.
Usually a hid miniport has no need to link against hidparse.sys though, or
are you referring to hidclass and hidparse coming in as one package?

As for the IDs, if the device is plugged into the serial port, then serenum
is the way to go. If this is an embedded device, have the bios change the
hw ID away from pnp0501 to your own hw id. you can then use serial.sys as a
lower filter (pens do this) to your miniport and you still use IRPs instead
of pounding directly on the hardware.

d

 

[Robert Marquardt]

I've got a ... charming ... customer that wants us to build a front panel
keypad, but they don't want to use USB... no, that would be too easy .
For "cost" reasons, they want us to make it a serial device and write a HID
minidriver for it. No worries, I'm working on them about that...

Especially if you can buy readymade USB+PS/2+ADB keyboard controllers.
(http://www.codemercs.com)

I have a question about such a device: Could it be WHQL'd?

There is a nice HID test program on the HID page of Jan Axelson
(http://www.lvr.com). It squeezes the bits out of HID minidrivers simply
by calling HID functions.
Older Logitech mouse minidivers failed with a BSOD. Older Kensington
minidrivers failed on all functions.

 

[Ray Trent]

Thanks for the info.

Re: HIDPARSE, I was merely noting that the vhidmini sample copies it as
part of the VHidMini "CopyFilesSYS" section.

This raises another interesting question, though, which is how does this
installation actually work? Doing a "devcon install vhidmini.inf
<pnpid>" as specified in the readme seems to create/install 2 devices.
One of them is an "empty" device with a PnPID of
"HID\MyVirtualHidDevice" (which is specified in the vhidmini sample inf
file). I can't quite grok how that happens, though, because there's no
obvious link in the INF file.

Is there some magic about copying hidclass.sys in the CopyFiles section?
Or is it a by-product of the driver registering as a HID minidriver in
it's DriverEntry (and how does that make its way back into the INF file
to extract the PNP ID of the fake device if so)...

 

[Eliyas Yakub [MSFT]]

That empty device is created out of custom top-level collection present in
the HID descriptor reported by the driver. If you look at the sample source,
you will see that the driver provides HID\MyVirtualHidDevice device-id for
the custom collection when it's queried. The readme file explains it all.