What's the KeyboardDataQueueSize for?

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)