PS/2 Keyboard
Overview
The PS/2 Keyboard is a device that talks to a PS/2 controller using serial communication. Ideally, each different type of PS/2 controller driver should provide some sort of standard/simple "send byte/receive byte" interface, and the PS/2 Keyboard driver would use this interface without caring about lower level details (like what type of PS/2 controller the device is plugged into).
The PS/2 Keyboard accepts commands and sends responses to those commands, and also sends scan codes indicating when a key was pressed or released.
Commands
A PS/2 Keyboard accepts many types of commands. A command is one byte. Some commands have data byte/s which must be sent after the command byte. The keyboard typically responds to a command by sending either an "ACK" (to acknowledge the command) or a "Resend" (to say something was wrong with the previous command) back.
The commands that a PS/2 Keyboard accepts are:
| Command Byte | Data Byte/s | Meaning | Response | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0xED | LED states:
Note: Other bits may be used in international keyboards for other purposes (e.g. a Japanese keyboard might use bit 4 for a "Kana mode" LED). |
Set LEDs | 0xFA (ACK) or 0xFE (Resend) | ||||||||||
| 0xEE | None | Echo (for diagnostic purposes, and useful for device removal detection) | 0xEE (Echo) or 0xFE (Resend) | ||||||||||
| 0xF0 | Sub-command:
|
Get/set current scan code | 0xFA (ACK) or 0xFE (Resend) if scan code is being set; 0xFA (ACK) then the scan code set number, or 0xFE (Resend) if you're getting the scancode | ||||||||||
| 0xF2 | None | Identify keyboard | 0xFA (ACK) followed by none or more ID bytes (see [| "Detecting Device Types"]) | ||||||||||
| 0xF3 | Typematic byte:
|
Set typematic rate and delay | 0xFA (ACK) or 0xFE (Resend) | ||||||||||
| 0xF4 | None | Enable scanning (keyboard will send scan codes) | 0xFA (ACK) or 0xFE (Resend) | ||||||||||
| 0xF5 | None | Disable scanning (keyboard won't send scan codes)
Note: May also restore default parameters |
0xFA (ACK) or 0xFE (Resend) | ||||||||||
| 0xF6 | None | Set default parameters | 0xFA (ACK) or 0xFE (Resend) | ||||||||||
| 0xF6 | None | Set default parameters | 0xFA (ACK) or 0xFE (Resend) | ||||||||||
| 0xF7 | None | Set all keys to typematic/autorepeat only (scancode set 3 only) | 0xFA (ACK) or 0xFE (Resend) | ||||||||||
| 0xF8 | None | Set all keys to make/release (scancode set 3 only) | 0xFA (ACK) or 0xFE (Resend) | ||||||||||
| 0xF9 | None | Set all keys to make only (scancode set 3 only) | 0xFA (ACK) or 0xFE (Resend) | ||||||||||
| 0xFA | None | Set all keys to typematic/autorepeat/make/release (scancode set 3 only) | 0xFA (ACK) or 0xFE (Resend) | ||||||||||
| 0xFB | Scancode for key | Set specific key to typematic/autorepeat only (scancode set 3 only) | 0xFA (ACK) or 0xFE (Resend) | ||||||||||
| 0xFC | Scancode for key | Set specific key to make/release (scancode set 3 only) | 0xFA (ACK) or 0xFE (Resend) | ||||||||||
| 0xFD | Scancode for key | Set specific key to make only (scancode set 3 only) | 0xFA (ACK) or 0xFE (Resend) | ||||||||||
| 0xFE | None | Resend last byte | Previously sent byte or 0xFE (Resend) | ||||||||||
| 0xFF | None | Reset and start self-test | 0xAA (self-test passed), 0xFC or 0xFD (self test failed), or 0xFE (Resend) |
Special Bytes
The keyboard sends bytes to the system. Some of these bytes have special meaning (e.g. responses from the commands above). The bytes the keyboard may send are:
| Response Byte | Meaning |
|---|---|
| 0x00 | Key detection error or internal buffer overrun |
| 0xAA | Self test passed (sent after "0xFF (reset)" command or keyboard power up) |
| 0xEE | Response to "0xEE (echo)" command |
| 0xFA | Command acknowledged |
| 0xFC and 0xFD | Self test failed (sent after "0xFF (reset)" command or keyboard power up) |
| 0xFE | Resend (keyboard wants controller to repeat last command it sent) |
| 0xFF | Key detection error or internal buffer overrun |
All other bytes sent by the keyboard are scan codes, where interpretation depends on the currently selected scan code set.
Driver Model
Command Queue and State Machine
Commands must be sent one at a time (e.g. if your driver is interrupt driven, you can't start sending a command within the IRQ handler because code outside the IRQ handler may be in the middle of sending a command). The command isn't completed until you've received an ACK for it. For example, if you send a command and the keyboard responds with "0xFE (resend)" then you have to send the command again (possibly limited to 3 retries before you give up and assume the keyboard doesn't support the command you're sending or there's been a hardware failure). Finally, sometimes you want to send several commands at once. For example, you might have a "reinitialise()" function that sets the scan code set, sets the typematic byte, sets the LEDs and enables scanning.
The simplest way to achieve this is for the driver to maintain a queue of commands. When you add a command to the queue, if the queue is empty you start sending the command; otherwise you append the command to the queue. When you receive an "0xFA (ACK)" from the keyboard you discard the command at the head of the queue and start sending the next command in the queue (if any). If you receive an "0xFE (Resend)" from the keyboard you can resend the command at the head of the queue.
The remainder of the driver should be a kind of state machine. The state machine moves into a different state when some commands are successfully completed, and when various bytes are received from the keyboard. For example, the driver might be in a default state and receive a break code that puts it into a "waiting for scan code after receiving break code" state. Then it might receive the first byte of a multi-byte scan code and shift to a "waiting for second byte of scan code after receiving break code" state. Finally it might receive the second/last byte of the scan code and then switch back to the default state.
Scan Code Sets, Scan Codes and Key Codes
A scan code set is a set of codes that determine when a key is pressed or repeated, or released. There are 3 different sets of scan codes. The oldest is "scan code set 1", the default is "scan code set 2", and there is a newer (more complex) "scan code set 3". Note: Normally on PC compatible systems the keyboard itself uses scan code set 2 and the keyboard controller translates this into scan code set 1 for compatibility. See "8042"_PS/2_Controller for more information about this translation.
Modern keyboards should support all three scan code sets, however some don't. Scan code set 2 (the default) is the only scan code set that is guaranteed to be supported. In theory (I haven't tried it) it should be possible to attempt to set scan code set 1 or scan code set 3, and then ask the keyboard which scan code it is currently using and see if it actually is using the requested scan code set. In this way it may be possible to determine which scan code sets the keyboard does support.
Scan codes themselves are sequences of one or more bytes. In some cases the sequence can be as many as 6 bytes (e.g. the "print screen" key in scan code set 1 generates the sequence 0xE1, 0x1D, 0x45, 0xE1, 0x9D, 0xC5 when pressed). This situation isn't really ideal. In general (for later processing) you want to convert these "one or more byte sequences" into a single integer that uniquely identifies a specific key, that can be used effectively in things like lookup tables (without having sparsely used "many GiB" lookup tables).
There is no standard for "key codes" - it's something you have to make up or invent for your OS. I personally like the idea of having an 8-bit key code where the highest 3 bits determine which row on the keyboard and the lowest 5 bits determine which column (essentially, the keyboard is treated as a grid of up to 8 rows and up to 32 columns of keys). Regardless of what you choose to use for your key codes, it should be something that is used by all keyboard drivers (including USB Keyboards) and could possibly also be used for other input devices (e.g. left mouse button might be treated as "key code 0xF1").
Basically, when the keyboard driver's state machine knows it has received a complete scan code, the next step is to convert the "one or more byte" scan code into a key code.
Key Codes, Key States and Key Mappings
Once you've got key codes, then next step is to keep track of which keys are currently being pressed. Imagine a computer game that uses the "WASD" keys for player movement - when the 'A' key is being pressed the player rotates clockwise. How does the game know if the 'A' key is currently being pressed? For this you'd want an array of flags, where each flag corresponds to a key code. There is a hidden bonus here - the keyboard driver itself can use the same "array of flags" to determine if a shift key, control key, alt key, etc is down, which can be quite useful when trying to convert the key code into an actual ASCII character or Unicode code point. For example, if the user presses the 'a' key then it might correspond to 'a' or 'A' (depending on capslock state and whether or not a shift key is being held down at the time) or might not correspond to a valid character at all (e.g. "control-a" or "alt-a").
Also note that (for example) a "WASD" game doesn't care if the keys are 'W', 'A', 'S' and 'D'. The game wants to know about keys in a specific "T-shaped" pattern on the left of the keyboard. If the keyboard happens to be something different, then the keys in the same location may be completely different (e.g. they would be '<', 'A', 'O' and 'E' keys on a Dvorak keyboard). This helps to explain my preference of having an 8-bit key code where the highest 3 bits determine which row on the keyboard and the lowest 5 bits determine which column (it's easy for a game to ask about the state of the third key on the left of the third row).
Once you're able to keep track of which keys are currently being pressed, the next step is to (attempt to) convert the key into an ASCII character or Unicode code point. At this point you need to know what type of keyboard the user has - is it "US QWERTY", or "French AZERTY", some form of Dvorak, or perhaps it's Arabic. To handle many different keyboard layouts, the keyboard driver needs to use tables to convert key codes into ASCII characters or Unicode code points; so that you only need to load a different "Key Mapping" table to support different keyboard layouts.
However, it's not quite that simple. Different keyboard layouts can have different meta keys, different status LEDs, etc. The Key Mapping table has to sort these differences out too. This is why you don't want to detect if the keyboard LEDs have changed earlier, but want to send the "set LEDs" command (if necessary) *after* you've found the entry for the key code in your key map table.
The final step of processing is to combine all relevant information into some sort of "keypress packet" structure, and send it to whomever (e.g. GUI). The entire "keypress packet" might include the following:
- Unicode code point (if applicable)
- Key code
- Pressed/released flag
- Various other key states (shift, alt, control, etc)
- Various "toggle" states (CapsLock, ScrollLock, NumberLock, etc)
Scan Code Set 1
The following table show what you should receive if a key is pressed or released when using scan code set 1 (for a "US QWERTY" keyboard only):
TODO
Scan Code Set 2
The following table show what you should receive if a key is pressed or released when using scan code set 2 (for a "US QWERTY" keyboard only):
TODO
Scan Code Set 3
The following table show what you should receive if a key is pressed or released when using scan code set 3 (for a "US QWERTY" keyboard only):
TODO
See Also
Threads
- Keyboard input
- Up or down press?
- Change typerate
- Converting the scancodes
- Discussion about keyboard input in a GUI
- Scroll-lock LED
- Keyboard LEDs (C source)
- Keyboard LEDs (asm source)
External Links
- www.Computer-Engineering.org
- KMT dk's ps2 keyboard and controller referance
- Keyboard scancodes - A complete reference on all scancodes you might encounter.