I am having a similar problem to the first thread, however, and I feel I am missing some relatively simple concept. I am using devcon and a single INF to install my HID shim driver (WDM) to a new device node, called something like root\MyDevice. I do not use the “customCollection” code from hidusbfx2 since I do not understand whether it is needed. I also have a KMDF filter driver that loads below the shim driver and handles internal IOCTLs. This works as expected, my shim + KMDF device shows up as a properly operating device under “Human Interface Devices”, and I get internal IOCTL requests for the HID descriptor and HID report descriptor.
I am using a plain report descriptor that matches the keyboard example from the HID DT.exe tool, and is very similar to the HID spec example. In fact, I believe it the keyboard report descriptor from here: http://www.microsoft.com/whdc/archive/w2kbd.mspx#ECAA
My understanding is that the HID system should automatically enumerate devices, create a new device (PDO is the proper term for it?), and assign the kbdhid.sys driver to that device due to my report descriptor. What I see happening is a “Other Devices->Unknown device” gets created, however, and the add new hardware wizard appears.
Do I need a second INF file in addition to the minidriver one, or is there something else I may be missing to get kbdhid.sys to properly link up and make the virtual keyboard device work by default?
I wanted to update and say that after some searching, I have found an example that seems to provide several virtual HID devices, and they actually do show up properly in device manager, so I should be able to use the example to figure out where I am going wrong with my auto-enumerated device that does not get a driver. The example has a popup about an unsigned driver when installed with devcon, even though I hit the F8 option to allow unsigned drivers in Vista, but otherwise it seems to work so I am going to try to follow what it does.
The example is here, for anyone who might need it: http://code.google.com/p/vmulti/ It is not my code or anyone I know, so I hope it is okay to link in the hopes that it may help other people who have trouble with HID devices and/or virtual devices. One thing I do not totally understand is the fact that the INF file in the example uses HID\vmulti as the device name. I got the impression that custom virtual devices should use something like root\vmulti, since HID should be reserved for auto-enumerated devices, but I could be wrong.
I will update further if I find out exactly why my virtual keyboard device did not end up automatically detected by kbdhid.sys.
Looking through the vmulti code definitely helped. I implemented the HID get string IOCTL like vmulti does, but I think the main issue was that I needed to add code to handle IRP_MJ_PNP/IRP_MN_QUERY_ID using WdfDeviceInitAssignWdmIrpPreprocessCallback in my EvtDeviceAdd function. Apparently handling this request and returning some sort of hardware ID triggers deep system magic in Windows, and device manager actually shows a HID keyboard device like it’s supposed to. Apparently Windows keeps polling such devices for read reports, however, so I will need to actually make it act like a keyboard next. I believe I can handle that with vmulti and other code to look at, however!
As always, any expert insight on concepts is appreciated since there are almost certainly things I do not fully understand. I hope the mailing list will forgive me replying to myself, but my current theory is that even if I solve some problems myself, including the solutions and relevant information in the thread will help future developers searching the internet with similar problems.
Hi I am the author of vmulti (hacked together from a few different WDK
samples),
I was also stuck before finding the IRP_MN_QUERY_ID trick (I cant remember
if I found that on this list or in the old vhid WDM sample from the vista
ddk).
I also cant remember why I used HID\vmulti instead of root\vmulti (maybe the
latter did not work for me).
It sounds like you should be able to synthesize keyboard events in short
order, just stick those requests that windows sends into a manual queue and
when you are ready complete them with data that matches your report
descriptor.
Cheers,
Daniel
On Tue, Nov 30, 2010 at 8:32 PM, wrote:
> Looking through the vmulti code definitely helped. I implemented the HID > get string IOCTL like vmulti does, but I think the main issue was that I > needed to add code to handle IRP_MJ_PNP/IRP_MN_QUERY_ID using > WdfDeviceInitAssignWdmIrpPreprocessCallback in my EvtDeviceAdd function. > Apparently handling this request and returning some sort of hardware ID > triggers deep system magic in Windows, and device manager actually shows a > HID keyboard device like it’s supposed to. Apparently Windows keeps > polling such devices for read reports, however, so I will need to actually > make it act like a keyboard next. I believe I can handle that with vmulti > and other code to look at, however! > > As always, any expert insight on concepts is appreciated since there are > almost certainly things I do not fully understand. I hope the mailing list > will forgive me replying to myself, but my current theory is that even if I > solve some problems myself, including the solutions and relevant information > in the thread will help future developers searching the internet with > similar problems. > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
Thanks, Daniel! I think I actually literally made a comment in my own code to email you, thanking you for the helpful example, but it looks like I can do so here instead.
You may be right that IRP_MN_QUERY_ID was in an older virtual HID device example. I understand that previous versions of the WinDDK had such an example of pure virtual HID devices, but it had been removed for whatever reaso.
Apparently Windows keeps polling such devices for read reports, however, so I will need to actually make it act like a keyboard next. I believe I can handle that with vmulti and other code to look at, however!