PS/2 Keyboard: Difference between revisions

The PS/2 Keyboard is a device that talks to a PS/2 controller using [[PS/2|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).

 

 

== Commands ==

 

 

The commands that a PS/2 Keyboard accepts are:

|-

| 0xED

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

|-

| 0xF0

|-

| 0xF2

| None

| Identify keyboard

|-

| 0xF3

| Set typematic rate and delay

| 0xFA (ACK) or 0xFE (Resend)

| Disable scanning (keyboard won't send scan codes)

Note: May also restore default parameters

| 0xFA (ACK) or 0xFE (Resend)

|-

| None

| Reset and start self-test

|}

 

== Special Bytes ==

|-

| 0xFA

|-

| 0xFC and 0xFD

All other bytes sent by the keyboard are scan codes, where interpretation depends on the currently selected scan code set.

 

 

 

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.

 

 

 

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#Translation|"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.

 

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).

 

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.

 

 

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").

* Various other key states (shift, alt, control, etc)

* Various "toggle" states (CapsLock, ScrollLock, NumberLock, etc)

 

==See Also==

*[[PL050 PS/2 Controller | PL050 PS/2 Controller (ARM)]]

*[[PS/2 Mouse]]

*[[Topic:9746|Keyboard input]]

*[[Topic:9761|Up or down press?]]

*[[Topic:9448|Discussion about keyboard input in a GUI]]

*[[Topic:9590|Scroll-lock LED]]

===External Links===

*[http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html Keyboard scancodes] - A complete reference on all scancodes you might encounter.

[[Category:Human Interface Device]]

[[Category:Common Devices]]