What's the KeyboardDataQueueSize for?

by Michael S. Kaplan, published on 2006/10/03 11:15 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/10/03/786095.aspx


The question was about the following registry key:

HKLM\SYSTEM\CurrentControlSet\Services\Kbdclass\Parameters\KeyboardDataQueueSize

It went something like this:

Could someone tell me if the default value of 100 on Win XP SP2 (EN-GB) means that 50 keystrokes will be buffered (as a result of DBCS) by the keyboard driver, or do we still use single-byte chars for things like the keyboard buffers, so 100 keystrokes will be buffered?

Now my first thought was simple enough:

The buffer has nothing to do with DBCS, it has to do with how many keystrokes are buffered for when no one is actually clearing the buffer, like if some process is busy enough to seem like it is hung).

It is before keystrokes are mapped to characters though, so character characteristics are not involved....

With that said, the truth is that some character entries may consist of two or even more keystrokes (in an IME you could need one or two for a pronunciation plus arrow keys to move down the candidate list, you could have chained dead keys, the Unicode IME takes four keystrokes, new text based TIPs in Vista could have combinations that take many keystrokes).

So the 100 can go faster than one might think! 

Now every word of that is true, but it also has nothing to do with the original registry key in question (thus hearkening to that old riddle about this proving I must work for Microsoft if I can have an answer is that is 100% true and 100% useless!). I had forgotten about the separation between the kernel mode piece of the USER subsystem (sometimes affectionately known as UserK (or userk or user/k, you get the picture) and the piece that runs in user mode. Luckily Hiro-san was able to clear things up:

Actually, the parameter is for the hardware and/or drivers, and has nothing to do with the hung application or whatever is happening in the user mode.

Apps don’t communicate directly with the drivers.  The RIT is reading the input from keyboard drivers, and distribute it to the application message queues.

If an app is hung and not retrieving the window messages, the input messages will pile up in the app’s own message queue, which is far more permissive than the narrow channels between the drivers and the RIT.

The registry key is for that queue on the kernel side, which is never the one that is hung up; it is those meaage queues back in user mode that can have all of the problems with hanging and such when theyare busy but someone keeps trying to type.

Though it is worth noting that the buffer in question is for keystrokes, long before any notion of even the possibility of an expectation of a character manages to come up. So perhaps my original thoughts are useful if you take out the misleading suggestion about who uses the 100 character buffer. :-)

 

This post brought to you by (U+0c9f, a.k.a. KANNADA LETTER TTA)


Tony Lee on 3 Oct 2006 11:54 AM:

Isn't the 50 because every key down is followed by a key up (excluding auto-repeat) and not because some key strokes take more than one byte?

Michael S. Kaplan on 3 Oct 2006 11:59 AM:

Its not really 50, it is 100 items in the queue -- which can be quite a few different mixtures of things (including the keyup and key down, as you mention). It is not counting individual keystrokes or anything like that....

Mihai on 3 Oct 2006 12:33 PM:

If it works like the old keyboard buffer it also stores the autorepeat keydown messages, so it can go quite fast.

On the plain-vanila PC, the keyboard 20 bytes circular buffer is maintainted by the BIOS (and the address is 0000:041e). The two words before the buffer point to the head and the tail, and making them the same was a popular way to "empty" the keyboard buffer.
Old times :-)

go to newer or older post, or back to index or month or day