HID vs. non-HID device differences

NTDEV
1

I am developing the driver(s) necessary to support a virtual *HID* mouse device stack.

Upon posting some questions regarding some issues related to this development, the following question was posed to me:

Do I really needed a virtual *HID* mouse, or just a virtual mouse?

As I reflected on this, I guess I came to the realization that I really do not know the difference, and therefore what advantage(s) might be served either way.

Is anyone able to shed any light on this topic?

BTW, the “goal” for my project is to be able to simply control mouse movements from
a disparate driver stack, autonomously from other existing physical mouse devices already present on the system.

Thank you in adance.
Mark H

2

A virtual mouse port driver and a virtual HID mouse do exactly the same thing. The difference is only where you implement your functionality to report input and how hard it is to so from each design. The advantage of a HID device is that you get the mouse stack for free, you just pump data into hidclass and you are done. A virtual mouse must support the mouclass IOCTL set and then report data via a service callback function pointer provided at init. Both have their own quirks, but typically a hid miniport or hidshim + hid driver beneath is a bit easier to implement.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@knowwareinc.com
Sent: Tuesday, January 29, 2008 11:44 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] HID vs. non-HID device differences

I am developing the driver(s) necessary to support a virtual *HID* mouse device stack.

Upon posting some questions regarding some issues related to this development, the following question was posed to me:

Do I really needed a virtual *HID* mouse, or just a virtual mouse?

As I reflected on this, I guess I came to the realization that I really do not know the difference, and therefore what advantage(s) might be served either way.

Is anyone able to shed any light on this topic?

BTW, the “goal” for my project is to be able to simply control mouse movements from
a disparate driver stack, autonomously from other existing physical mouse devices already present on the system.

Thank you in adance.
Mark H

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

3

No, you don’t need a HID device stack to do this.

xxxxx@knowwareinc.com wrote:

I am developing the driver(s) necessary to support a virtual *HID* mouse device stack.

Upon posting some questions regarding some issues related to this development, the following question was posed to me:

Do I really needed a virtual *HID* mouse, or just a virtual mouse?

As I reflected on this, I guess I came to the realization that I really do not know the difference, and therefore what advantage(s) might be served either way.

Is anyone able to shed any light on this topic?

BTW, the “goal” for my project is to be able to simply control mouse movements from
a disparate driver stack, autonomously from other existing physical mouse devices already present on the system.

Thank you in adance.
Mark H

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

4

Hmmm …

If I understand - one guru suggests that the HID stack implementation is a bit easier, and another suggests quite the opposite, that a non-HID function driver is simpler.

I hope I was clear on the goal: communication *from* an already existing KMDF driver in the system *to* this (new) virtual mouse device, with the added requirement that it neither effect existing physical devices already present *nor* require installation of a new physical device, i.e. a mouse filter on an existing i8042 stack is *not* an option.

I have the utmost respect for their valued input, and am certainly grateful for any material here that helps the edification on the way to a solution for my project; but I guess I am wondering why the suggestions differ so? Certainly there is more to the content on this one than “personal style” differences would dictate.

Thank you in advance once again,
MarkH

5

I suspect it just comes from different kinds of unpleasant experiences.
I admit I was surprised to hear Doron say that a hid miniport/shim
driver was easier since he has previously advocated making a function
driver if all you want is mouse functionality…

But it does, indeed, come down to personal preference. I prefer less
complicated installation scenarios and find the HID stack confusing and
finicky, whereas it sounds like Doron doesn’t enjoy dealing with unique
IOCTL and callback interfaces.

Neither kind of driver is inherently all *that* complex. I think we
would both agree you should use KMDF in either case.

In any event, even though I’ve been working on mouse drivers for the
last 11 years, Doron is much more of a guru than I am, so if you’re
looking for a more authoritative source he’s your man.

xxxxx@knowwareinc.com wrote:

Hmmm …

If I understand - one guru suggests that the HID stack implementation is a bit easier, and another suggests quite the opposite, that a non-HID function driver is simpler.

I hope I was clear on the goal: communication *from* an already existing KMDF driver in the system *to* this (new) virtual mouse device, with the added requirement that it neither effect existing physical devices already present *nor* require installation of a new physical device, i.e. a mouse filter on an existing i8042 stack is *not* an option.

I have the utmost respect for their valued input, and am certainly grateful for any material here that helps the edification on the way to a solution for my project; but I guess I am wondering why the suggestions differ so? Certainly there is more to the content on this one than “personal style” differences would dictate.

Thank you in advance once again,
MarkH

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

6

Well, I have the virtual mouse stack working, using the HID minidriver approach.
The system shows a HID-compliant mouse, which is just what I want!

1/ The last couple of days I have been struggling with the whole HID collection/reports “interface” (if you want to call it that!). I have been writing/debugging all types of device drivers on MS platforms for almost 10 years now, and very well understand that “things are not always as they seem”, but I gotta tell ya … I am not one to post here w/out first doing what research I can, including checking w/ colleagues, but the whole HID collection scheme to me seems very complex. I understand this is meant for all types of devices, and is very flexible - and I would like to, in fact, leverage some of this flexibility - but trying to determine what to “pump into the HID class” just to move the mouse has me confused. Anyone able to lend some insight here?

2/ On another note (possibly a different topic?), I added a KMDF mouse filter, based on the KMDF kbfilter, of course, and this was not much effort at all. I can send MOUSE_INPUT data from a user IOCTL for test purposes, and this is an approach that may work for me. Problem here, is the real functionality requires calling from a different driver stack.
I tried to come up speed with the use of ‘WdfIoTargetQueryForInterface’, as (little) prescribed in MSDN docs, but this does not seem to be a widely used interface. I believe the “callee” aspect is OK - as far as ‘WdfDeviceAddQueryInterface’ (thanks to Doron’s blog post at http://blogs.msdn.com/doronh/archive/2007/03/12/supporting-query-interface-in-kmdf.aspx) - but is this really the recommended way for KMDF drivers to call across device stacks?
Is there a different approach, or do I just need to suck it up and perservere?

Once again, thank you all in advance.
MarkH