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 ?
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.
Related
I made a custom USB sensor device that runs on a Windows 8.1 / 10 desktop computer using the WinUSB driver (I implemented Microsoft extended USB descriptors in device firmware to automatically install the driver when the device connected).
Can I use a WinUSB device on HoloLens2? Or, if there is no WinUSB support on HoloLens2, how can I use my USB device with a “custom USB device class”?
At the moment, I do not have a hololens2, but I need to understand how the USB works on it.
Edit: I found this link: https://learn.microsoft.com/en-us/hololens/hololens-connect-devices#hololens-2-connect-usb-c-devices
It says that hololens2 supports the following device classes:
Mass storage devices (such as thumb drives)
Ethernet adapters (including ethernet plus charging)
USB-C-to-3.5mm digital audio adapters
USB-C digital audio headsets (including headset adapters plus charging)
Wired mouse
Wired keyboard
Combination PD hubs (USB A plus PD charging)
My device does not implement any of these classes (custom class). Is there a chance to make it work on hololens2?
I finally tested my code and USB device on real Hololens 2. The USB device works great there because Hololens2 supports WinUSB! The WinUSB driver was installed automatically (my device has WinUSB descriptors).
According to the documentation you referred, all classes HoloLens2 supports have been listed, and unlisted classes are not supported.
Could you provide more information about your business request and submit a feature request via feedback hub on new feature request to be considered in future releases of HoloLens OS and devices?
If it’s a hot impacted feature, it will be possible to be given priority to jump in the development schedule. Actually, the existing classed on HoloLens 2 are also based on user’s feedback in such way.
For how to post feedback request, you can follow this doc: Send feedback to Microsoft with the Feedback Hub app.
What is the additional advantage of developing a full UMDF windows driver if a CDC device is detected as a virtual COM port?.
I have some experience with embedded examples using a microcontroller, both communicating with a terminal like teraterm or using a dedicated USB peripheral that allows for cdc or hid functionality.
Are these drivers the ones you download and install before using any USB device? It is not clear yet what features are avaialble through the host driver.
Often on Windows the "driver" for a USB serial device is no more than an inf file that maps the device VID/PID to the Microsoft usbser.sys CDC/ACM driver.
Recent releases of Windows 10 appear to have stopped insisting that each CDC/ACM have a VID/PID specific inf file, and will load the standard driver for any device that presents as a CDC/ACM device.
The advantage of having a VID/PID specific inf file is that your device can have a vendor specific "friendly name" which can be used in applications to more easily identify your device, rather than just appearing as a generic "USB Serial Device".
One problem with Microsoft's usbser.sys driver (and Linux and Mac OS are no different) until recently was that if you disconnect the USB device, the driver is unloaded even if an application has the COM port open, and the application must close and reopen the port to recover when reconnected. I have previously used a custom driver (provided by a third party), that does not unload if an application has the port open, so that when the USB cable is reconnected, the data connection continues as normal, just as it would if it were an RS-232 cable. However, again in recent versions of Windows 10 I have noticed that usbser.sys appears to exhibit this behaviour in any case.
Note that when you do provide your own driver file, or even just a custom inf file, you will be required to go through WHQL testing in order for your device to be allowed on Windows 10, or to load without warnings on earlier versions. To do that you will need a USB.org assigned VID, an Extended Validation code-signing certificate, and either the tools and facilities to perform the testing, or pay a test house to perform the testing. That all gets somewhat expensive, and may be prohibitive for low volume, low value or non commercial products.
At one time Microsoft too charged for WHQL processing submissions, but no longer do so. That is however little combination since at the same time they changed to requiring an EV certificate and stopped a deal the used to have for low-cost certificate.
The advantage of WHQL qualification is your driver will be provided by Windows Update.
If you are using a USB serial bridge chip rather than your own USB stack and USB controller, then there is a lower cost solution. These chips can be customised with your own VID/PID and descriptors, and the vendor's existing WHQL can be associated to your device so you get all the advantages of your own driver without the costs. Most vendors will even allow you to use their VID and will assign you a unique PID so you can avoid USB.org fees. I have used this route with both Prolific and FTDI devices; it is by far the most cost effective solution.
I want to communicate my product string to Windows so that the STM32 device doesn't show as a 'USB Input Device' under the device manager. Is this information derived from the PID/VID, or is there a way for me to communicate a custom product string?
The device itself has various identifications including vendor strings and the VID/PID. You will see these in Device Manager while the device is "unknown" and Windows searches for a driver.
However when Windows matches the VID/PID to a device driver, it uses the strings in the associated driver .ini file rather than those provided by the device.
For a signed driver however, modifying the INI file is not possible with out re-singing it, and Windows will not normally allow unsigned drivers. Moreover recently in Windows 10, drivers must be approved and signed by Microsoft; and you still need your own EV certificate in order to submit your driver for approval. Obtaining your own VID and EV code signing certificate are not free, and testing of drivers for Windows qualification is not straightforward, and service providers to do that for you are expensive too.
How is it possible to determine the commands to operate a usb device, if that device comes from another operating system and traffic monitoring software cannot be installed on that OS. The only method i can think of is sending random commands to the device, until the device responds, but this seems implausible for more complex commands, and potentially dangerous. For example, consider the DualShock 4 controller. Sony has not made an official driver for this device, so what method can i use to create a linux driver for it?
Get a hardware protocol analyzer. Then you won't need to install any software on the host or device under test. Here is one that I have used:
http://www.totalphase.com/products/beagle-usb12/
I have been tasked with writing a USB driver for our embedded software to send raw data to Host. This will be used to send some logging data to host. We are using iMX31 litekit for development.
From the documents that I have read on USB, my understanding is that the embedded device will be in device mode only. Also it will only be communicating with host machine.
So can any one guide me here? Any article, reference or code is welcome.
Some things to consider:
Is this a high bandwidth device like a camera or data recorder, or a low bandwidth device?
For low bandwidth, I would strongly consider making your device act as a USB HID class. This is the device class that supports keyboards, mice, joysticks, gamepads, and the like. It is relatively easy to send data to nearly any application, and it generally doesn't require that you write a custom device driver on the host side. That latter feature alone is often worth the cost of lightly contorting your data into the shape assumed by the HID class. All the desktop operating systems that do USB can use HID devices, so you get broad compatibility fairly easily.
For high bandwidth, you would still be better served if your device fits one of the well established device classes, where a stock device driver on the host end of the wire can be used. One approach that often works is to use the Mass Storage class, and emulate a disk drive containing one file. Then, your device simply mounts on the host as if it were a disk, and you communicate by reading and writing to one (or a few) file.
I would expect there to be a fair amount of sample code out there for any serious USB device chipset that implements either or both of HID and Mass Storage.
If you really must wander into fully custom device territory, then you will need to be building device drivers for each host platform. The open source libusb library can be of some help, if its license is compatible with your project. There are also ways in newer versions of Windows to develop USB drivers that run in user mode using the User Mode Driver Framework that have many of the same advantages of libusb, but are not portable off the Windows platform.
The last custom device I worked on was based on a Cypress device, and we were able to ship their driver and an associated DLL to make our application code easier to build. I don't know off the cuff if there is any equivalent available for your device.
For a really good overview, I recommend the USB FAQ, and the latest edition of Jan's book, USB Complete.