I am writing a driver and software for a client who has an existing driver I am asked to work with (or around) in certain situations – which I have no control over, or source code for. The device is supposed to have a HID compatible interface, but shows up with hardware IDs like “USB.…” and not “HID.…”. The USB device descriptor bDeviceClass is 0xFF.
Is it possible to create a user mode app to use their “HID compatible interface” even when the existing driver registers this as a vendor-specific device class, instead of the HID class?
Is the USB stack capable of exposing HID collections to user mode apps, even without the HID class being explicitly linked in the descriptors, or anything special being done by the legacy third third party driver?
I assume that it is not possible to match my own kernel driver to the VID and PID of this device simultaneously with the legacy third party driver.
xxxxx@yahoo.com wrote:
I am writing a driver and software for a client who has an existing driver I am asked to work with (or around) in certain situations – which I have no control over, or source code for. The device is supposed to have a HID compatible interface, but shows up with hardware IDs like “USB.…” and not “HID.…”. The USB device descriptor bDeviceClass is 0xFF.
Is it possible to create a user mode app to use their “HID compatible interface” even when the existing driver registers this as a vendor-specific device class, instead of the HID class?
Absolutely, but you won’t be able to use the HID libraries to do so. If
they have an existing driver, then they must have some kind of an
interface already created. Do you have documentation on the existing
driver?
Is the USB stack capable of exposing HID collections to user mode apps, even without the HID class being explicitly linked in the descriptors, or anything special being done by the legacy third third party driver?
No. If the interface really is compatible with the USB HID Class, you
could write a tiny filter driver underneath the stock usbhid driver to
tweak the descriptors. If not, then someone would have to translate
their interface to HID collections
I assume that it is not possible to match my own kernel driver to the VID and PID of this device simultaneously with the legacy third party driver.
No, but why do you need the third-party driver? If it really is
supposed to work like a HID device, just throw their driver out and use,
for example, WinUSB to talk to the interface directly.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks for the helpful info, Tim.
The approach I described seems like a dead end based on your comments; so we are going to tweak the firmware and do this a different way.
Andrew,
You can develop an upper filter driver for your USB driver that would expose a HID PDO, basically a simple bus driver. You’ll also have to put together a basic HID miniport to be installed on that PDO. A combination of that HID miniport and the bus filter would do what you want. It may be slightly more development that you wish but it will do exactly the job you’ve specified. WDK has straightforward enough samples for bus & filter drivers as well as HIDCLASS miniports.
Regards,
Ilya Faenson
Rockville, MD USA