Virtual Keyboard Driver: What to mimic?

NTDEV
1

Hello,

I have written a virtual keyboard function driver and call KeyboardClassServiceCallback to simulate keyboard events.

I used pnpi8042’s default properties of an Enhanced 101/102-key keyboard, but now I’d like to trim it down.

Is it safe to report a total number of keys of zero, an input data queue length of zero, minimum & maximum delay & repeat rates of zero and no indicator lights?

If I report no indicators, how should I respond to IOCTL_KEYBOARD_SET_INDICATORS?
Should I just ignore it and complete the IRP with success or should I always report failure?

Thanks.

2

Some of these values are reported, but no one looks at them. But think
about it, a queue length of zero? You have to have at least one or else
you can’t ever report a key? I think you want to support the
indicators, I think a failure of the query leads to undefined behavior.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hushmail.com
Sent: Sunday, July 15, 2007 10:44 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Virtual Keyboard Driver: What to mimic?

Hello,

I have written a virtual keyboard function driver and call
KeyboardClassServiceCallback to simulate keyboard events.

I used pnpi8042’s default properties of an Enhanced 101/102-key
keyboard, but now I’d like to trim it down.

Is it safe to report a total number of keys of zero, an input data queue
length of zero, minimum & maximum delay & repeat rates of zero and no
indicator lights?

If I report no indicators, how should I respond to
IOCTL_KEYBOARD_SET_INDICATORS?
Should I just ignore it and complete the IRP with success or should I
always report failure?

Thanks.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

Thanks for your reply.

Doron Holan wrote:

But think about it, a queue length of zero?
You have to have at least one or else you can’t ever report a key?

According to Microsoft’s documentation, KEYBOARD_ATTRIBUTES.InputDataQueueLength “specifies the size, in bytes, of the input data queue used by the keyboard port driver”.

My port driver doesn’t have any input data queue, because it just “exports” pointers to its device object and KeyboardClassServiceCallback, so all input is injected from outside.

As far as I know, kbdclass grants every keyboard an equally sized internal input buffer, so InputDataQueueLength is just some arbitrary value in my case.

Am I wrong?

4

Sorry, to avoid a misunderstanding:

With “equally sized internal input buffer”, I mean kbdclass allocates an internal input queue with the same size for every keyboard device regardless of its reported InputDataQueueLength.

5

Correct, you can see this in the kbdclass code that is in the WDK. My
point is that if you are ever going to report a packet, technically
speaking, you have a queue length of at least one. If you are never
going to report anything, you can put a queue length of zero. You are
IMHO over optimizing here, the value doesn’t matter. The indicator
mappings don’t matter, nor do the set indicator/typematic calls. Just
complete these requests synchronously and you are done with it

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hushmail.com
Sent: Monday, July 16, 2007 5:06 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Virtual Keyboard Driver: What to mimic?

Sorry, to avoid a misunderstanding:

With “equally sized internal input buffer”, I mean kbdclass allocates an
internal input queue with the same size for every keyboard device
regardless of its reported InputDataQueueLength.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

6

I have another question about one of pnpi8042’s I8xInternalDeviceControl’s comments:
“This routine cannot be paged because the class drivers send down internal IOCTLs at DISPATCH_LEVEL.”

I have tried to verify this by analyzing kbdclass and it seems like this remark does not apply.

I have also installed a filter driver with a pageable dispatch routine and it just works.

Should I play along and prohibit paging for my dispatch routine or is this comment simply obsolete, etc.?

7

xxxxx@hushmail.com wrote:

I have another question about one of pnpi8042’s I8xInternalDeviceControl’s comments:
“This routine cannot be paged because the class drivers send down internal IOCTLs at DISPATCH_LEVEL.”

Perhaps that should read “…because the class drivers MAY send down
internal IOCTLs at DISPATCH_LEVEL.”

I have tried to verify this by analyzing kbdclass and it seems like this remark does not apply.

All that means is that you haven’t yet encountered a case where it
happens. I hope you do not actually interpret this to mean that it
CANNOT happen.

I have also installed a filter driver with a pageable dispatch routine and it just works.

That could mean that your dispatch routine has never actually needed to
be paged out, and/or that you haven’t yet been in a circumstance where
the IOCTL arrived at DISPATCH_LEVEL.

Should I play along and prohibit paging for my dispatch routine or is this comment simply obsolete, etc.?

Unless you have a megabyte of code in there, I think you have already
expended more time on this than it is worth. Look at the cost/benefit
ratio. If the comment is wrong and you leave your dispatch routine
non-paged, the cost is one page of locked kernel memory. But if you
choose to disbelieve the comment and it does eventually come true six
months from now, you have an unhappy customer.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

8

You’re certainly right about the cost-benefit ratio,
but even Microsoft’s own kbfiltr & moufiltr have
pageable KbFilter_InternIoCtl resp. MouFilter_InternIoCtl
routines.