Question

Hi we are a embedded development company (www.emfocus.co.in) and new to driver signing details.currently we are developing a driver for a UPS is just a generic USB HID class device.The device firmware has been written in such a way that the UPS will be enumerated as a Human Interface device

But our intention is to treat our UPS as a HID UPS Battery - a battery class device, instead of a generic HID device. So that when we connect our UPS to the Windows, Windows will detect the UPS as a battery connected to the system and the Windows power manager will communicate to the UPS through HID interface. The HID interface here I mentioned in the driver is not just a generic interface. Its HID Power Device Interface. We defined HID Power Device report descriptor in our mini driver, so that the Windows will enumerate a Top Level Collection which is the HID UPS battery for our UPS. That HID UPS Battery top level collection has been implemented in our mini driver. Actually we can use the Windows InBox driver if we have written the device firmware in such a way that it will enumerate a battery top level collection. But our device firmware is written to enumerate as a generic HID device.

Once the HID UPS Battery has been detected by the Windows, the Windows itself starts sending Feature Report requests for getting Battery Capacity, RunTimeToEmpty, AC Present, Charging status... every thing is working fine.

While those requests are issued to our driver, our driver will communicate to the UPS over USB (with its proprietary protocol) and get the status parameters from the UPS and the driver finishes the IOCTL_HID_GET_FEATURE request with the required values in the feature report and Windows Power Manager displays the status on the Power meter.

So that the UPS battery status will be monitored on the Windows Power Meter itself, since Windows considers our UPS as a HID UPS Battery and not a generic HID device after installing our driver.

We want to have the Windows select our driver inf file at all times while looking for best matching driver files.

So to achieve this we want to know if its ok to sign our driver with our code signing certificate or to get the driver WHQL certified ?

Was it helpful?

Solution

If you are just looking to get your device "installable" on an end users system without warnings or signing errors you can create catalog files for the INF installation and sign them with your code signing certificate. The downside to this is that you have to distribute and install the certificate to your users' machines as a trusted publisher before trying to install the device through it's INF.

Alternatively running through the WHQL HCK tests will require that you acquire test logs (for each OS) and submit them to Microsoft for a fee to review and provide a WHQL signature on CAT files created through the HCK submission process. This route is the cleanest for the user because it requires no certificate distribution and also proves that your device passes the WHQL HCK tests.

So the answer depends on what you are trying to do and who your target audience is. I would opt for the WHQL route if you can afford it, as it provides the most benefit for the end users.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top