KMDF virtual HID mouse

MarkH · January 25, 2008, 10:17pm

I am developing a “virtual HID mouse” device. Ideally, I would like it to be a KMDF driver. I am looking at the DDK examples for VHIDMINI and the 6001 HIDUSBFX2 as starting examples. Since I do not have a real physical device, I am fine with installing it as a root-enumerated software-only driver.

Right now, I am leaning towards the approach of using the HIDKMDF mapping driver from HIDUSBFX2 for the minidriver (as is), and then modifying KBFILTER to be a KMDF MOUFILTR lower filter, replacing the HIDUSBFX2 lower filter that exists in that sample.

This brings to mind a couple of questions (that are quite possibly all related):

a/ Can the filter just forward the PnP IRPs (oops -“requests”) to the root-enumerated PDO?

b/ Where does the “input device PDO” (lowest on device stack) even come from, i.e. how is it created?

c/ Looking a the INF file from the VHIDMINI example - since that too is a software-only driver - what is the meaning of the GUID that is passed to ‘devcon’ during installation?
Can I use my own GUID here, or does that particular one have a certain class association?

d/ More on installation - I have previously modified the KBFILTER example successfully for a separate project, and the installation technique from OSR article 446 proved to be quite handy. Ideally, I would prefer an installation much like this (vs. the ‘devcon’ approach).
Is there a way to adapt this for the “minidriver portion” of the installation? I just am not sure of the INF entries required for that, and if that is even possible.

Thank you in advance for any feedback here.

Mark

Alyah_Nihal · January 26, 2008, 4:34am

I’m sorry for not answering any of your questions, but do you really need a virtual *HID* mouse, or just a virtual mouse?

Doron_Holan · January 26, 2008, 10:52pm

a) are you starting with the WDM or KMDF version of kbfilter? If you start with the KMDF version and convert it to be a mouse filter, this question is moot since KMDF handles pnp irps for you entirely.

b) which PDO are you talking about? In the hid stack there is the HID parent and then the HID enumerated PDO

if you are talking about the PDO for the parent stack and you are writing a software only driver, the pnp manager root enumerator enumerates the PDO for you. This brings me to another question. Moufilter is designed to filter between mouhid (or any mouse “port” driver) and mouclass, not as a parent HID stack filter. I think once you clear up where in the stack you are filtering and what you are trying to do (As a goal, not as the implemention for a driver that does “this”) I think things will become clearer.

c) do you mean this guid?
%VHidMini% = VHidMini.Inst, {D49F883C-6486-400a-8C22-1A9EF48577E4}\HID_DEVICE

If so, then yes you should (actually must) use your own GUID here. The GUID is a part of the hardware ID that identifies your device. You only need to create a GUID here if your device is a software only device. If some bus (usb, Bluetooth, green feet) enumerates your stack, the bus will provide you with the hardware ID that you match against in the INF (and specify on the devcon command line if you install that way).

d) since this is a pnp driver (and really a device lower filter, not a class lower filter), you do not need the hoops that this article talks about. Just install the device via an INF and use the appropriate entries to point to the KMDF coinstaller. The 6001 WDK sample which has the hidusbfx2 driver will have INF which does everything you need to do. Just replace references to hidusbfx2 with your driver name and replace the hardare ID in the [vendor] section.

d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@knowwareinc.com
Sent: Friday, January 25, 2008 7:19 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF virtual HID mouse

I am developing a “virtual HID mouse” device. Ideally, I would like it to be a KMDF driver. I am looking at the DDK examples for VHIDMINI and the 6001 HIDUSBFX2 as starting examples. Since I do not have a real physical device, I am fine with installing it as a root-enumerated software-only driver.

Right now, I am leaning towards the approach of using the HIDKMDF mapping driver from HIDUSBFX2 for the minidriver (as is), and then modifying KBFILTER to be a KMDF MOUFILTR lower filter, replacing the HIDUSBFX2 lower filter that exists in that sample.

This brings to mind a couple of questions (that are quite possibly all related):

a/ Can the filter just forward the PnP IRPs (oops -“requests”) to the root-enumerated PDO?

b/ Where does the “input device PDO” (lowest on device stack) even come from, i.e. how is it created?

c/ Looking a the INF file from the VHIDMINI example - since that too is a software-only driver - what is the meaning of the GUID that is passed to ‘devcon’ during installation?
Can I use my own GUID here, or does that particular one have a certain class association?

d/ More on installation - I have previously modified the KBFILTER example successfully for a separate project, and the installation technique from OSR article 446 proved to be quite handy. Ideally, I would prefer an installation much like this (vs. the ‘devcon’ approach).
Is there a way to adapt this for the “minidriver portion” of the installation? I just am not sure of the INF entries required for that, and if that is even possible.

Thank you in advance for any feedback here.

Mark

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

MarkH · January 28, 2008, 5:41pm

Thank you, Doron, for your reply.

My basic problem, I believe, is coming up with the (parent) lower device stack, the one with the PnP manager root-enumerated PDO. If I understand what needs to be done, I need to create a device lower filter to sit between the KMDF HID miniport and the root PDO; this driver will be similar to the HIDUSBFX2.SYS component, but without the knowledge of the USB hardware. Is this correct?
If so, might the driver itself from the OSR article 446 be useful?

As I write this now, I am wondering if that is even necessary - is this filter absolutely necessary, per your “ascii” architecture depiction?

The main *goal* of what I am trying to accomplish is to simply control mouse cursor autonomously from any (other) actual physical mouse device(s) present in the system.

Primarily, I am going to require communication from both user-mode and kernel mode to this device stack. I was thinking of creating a sideband RAW PDO for this I/O, similar to that in the KMDF KBFILTR sample. In your mind, can I employ the same technique from that sample? That is, perhaps invoke the routine that creates that RAW PDO from the EvtDeviceAdd routine in this new filter driver? Or, if it turns out that the filter driver is not needed, for example, could this possibly be done from the HID “mapping miniport” driver?

Thank you once again in advance.

Mark

Ray_Trent · January 29, 2008, 3:52pm

Depending on your purpose for doing this, you may be able to get away
with a user-mode app using SendInput.

However, if you find that you need a kernel mode driver (e.g. if you
need to be able to control elevated and Session 0 apps… i.e. probably,
if you want to support Vista… sigh), it’s a lot easier to just make a
mouse *function* driver rather than a HID filter driver.

Do be aware that those aforementioned limitations are for security
reasons, and if you expose a user-mode interface to this kernel driver
you could potentially be creating a security vulnerability.

Anyway, search MSDN and the list archives for numerous examples of how
to do this.

xxxxx@knowwareinc.com wrote:

Thank you, Doron, for your reply.

My basic problem, I believe, is coming up with the (parent) lower device stack, the one with the PnP manager root-enumerated PDO. If I understand what needs to be done, I need to create a device lower filter to sit between the KMDF HID miniport and the root PDO; this driver will be similar to the HIDUSBFX2.SYS component, but without the knowledge of the USB hardware. Is this correct?
If so, might the driver itself from the OSR article 446 be useful?

As I write this now, I am wondering if that is even necessary - is this filter absolutely necessary, per your “ascii” architecture depiction?

The main *goal* of what I am trying to accomplish is to simply control mouse cursor autonomously from any (other) actual physical mouse device(s) present in the system.

Primarily, I am going to require communication from both user-mode and kernel mode to this device stack. I was thinking of creating a sideband RAW PDO for this I/O, similar to that in the KMDF KBFILTR sample. In your mind, can I employ the same technique from that sample? That is, perhaps invoke the routine that creates that RAW PDO from the EvtDeviceAdd routine in this new filter driver? Or, if it turns out that the filter driver is not needed, for example, could this possibly be done from the HID “mapping miniport” driver?

Thank you once again in advance.

Mark

–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)