OSDev.org

While I've found many useful resources on handling interrupts and writing a keyboard driver, there's one aspect of it that has bothered me from the start, which is the presence of scancodes which are multiple bytes long. There's a couple of questions I've had from the beginning:

1. Can the keyboard encoder's buffer contain more than one scancode at a time?
2. If so, does the protocol provide a way to determine where each one ends?
3. If not, can you tell where an unrecognized scancode ends just from looking at it?

None of the resources I've found really seem to address this, which suggests to me that the answers are precisely what I don't want to hear:

1. Of course.
2. No.
3. Maaaayybe for set 3? But even then, probably best to still anticipate exceptions to the rule.

Which implies that (other than maaaaaybe set 3) there's no way to handle unrecognized scancodes cleanly (i.e. without impacting the reading of other scancodes), and thus you need to have a complete lookup table of all the scancodes that are possible. This seems impossible in general considering hardware differences and etc.. Can somebody please tell me I am wrong, and if not: how does one deal with this?

Hi,

exphp wrote:1. Can the keyboard encoder's buffer contain more than one scancode at a time?

Yes, and for most keyboards there's an internal buffer able to hold the scancodes for multiple key presses.

exphp wrote:2. If so, does the protocol provide a way to determine where each one ends?
3. If not, can you tell where an unrecognized scancode ends just from looking at it?

Typically (it depends on which scan code set you're using) there's one or more special escape codes, then a one byte final scan code; and you just have a little state machine and switch to a different state when you receive one of the special escape codes, and then return to the default state when you receive anything else (the last byte of the scan code).

However there are a few keys that didn't exist originally where the same functionality was done by the user by pressing a sequence of 2 keys. When these were given their own dedicated key later they decided to make the key pretend to be 2 keys and send the scancodes for both of those 2 pretend keys. An example of this is the "print screen" key, which is actually an "escape, left shift, escape, keypad *" sequence. Fortunately the escapes make it easy enough to handle this with your state machine.


Cheers,

Brendan

Hi, thanks for the response. You're right, even the set 2 codes are a lot more structured than I initially thought. Looking closely at the PAUSE sequence, I gather that this used to be accomplished by pressing Num Lock while holding control?

I've been working on it for quite a bit today, and now have a decent amount of code for parsing set 2 scancodes that I'm waiting to test. Though, it looks like I've got another issue on my hands, as nothing changes when I try to change the scancode set! Looking around, it appears that I have overlooked some steps involving more initialization of the PS/2 port, including disabling some dastardly "translation" feature which sounds like an awful lot like my problem...