Chapter 19. Keyboards

A keyboard is a matrix of individual switches, one per key. Pressing a key closes its switch, generating a signal that the dedicated keyboard controller built into the keyboard recognizes as the make code for that key. Releasing the key opens the switch, which the keyboard controller recognizes as the break code for that key. Using a firmware lookup table, the keyboard controller translates received make code signals to standard scan codes, which it sends via the keyboard buffer to a second keyboard controller located in the PC, which recognizes those scan codes as specific characters and control codes.

Because releasing a key generates a break code, the local keyboard controller can recognize when two keys are pressed together (e.g., Shift-A or Ctrl-C) and generate a unique scan code for each such defined key combination. For undefined key combinations (e.g., pressing "a" and then pressing "s" before releasing "a"), the keyboard controller recognizes that, even though a break code for "a" has not been received, the user's intent is to type "as", and so generates the scan code for "a" followed immediately by the scan code for "s".

Most people do not need to work with scan codes directly, but if you program you may need to use scan codes to control the behavior of a program when the user presses specific keys or key combinations. The Microsoft Keyboard Scan Code Specification, which includes the standard keyboard scan codes as well as alternative make and break PS/2 scan codes and USB code responses for the Windows Key, Application Keys, and ACPI power controls, is available from http://download.microsoft.com/download/whistler/hwdev3/1.0/WXP/EN-US/scancode.exe. Microsoft also publishes the USB HID to PS/2 Translation Table, which provides mappings from the USB HID keyboard multimedia usages to PS/2. That file is available in PDF format from http://www.microsoft.com/hwdev/download/tech/input/translate.pdf or in Excel format from http://www.microsoft.com/hwdev/download/tech/input/translate.xls.

Communication between the two keyboard controllers is bidirectional and asynchronous, which allows the PC to illuminate and extinguish keyboard indicator lights and set Typematic parameters such as delay and repeat rate. The keyboard interface was standardized with the 1984 introduction of the IBM PC/AT, which means that any AT-class keyboard works with any 286 or higher PC, assuming that the physical connectors are compatible.

In addition to basic functions, the local keyboard controller may support various programmable functions, using either or both of these methods:

Keyboard-based

The local keyboard controller may support creating custom definitions for specific keys and key combinations and storing those definitions in the keyboard itself. When a key with a custom definition is pressed, the local keyboard controller generates the necessary scan codes directly and sends them to the PC. Because this method uses only standard scan codes, it has the advantage of not requiring a driver on the PC—which means the programmable functions can be used with any operating system—but the disadvantage of being limited to functions that can be performed using standard scan codes. This method was commonly used with early programmable keyboards, but is less common nowadays.

PC-based

Programmable functions may require a driver running on the PC. That driver recognizes nonstandard scan codes generated by the local keyboard controller and takes whatever action the driver defines for "hard-wired" special keys. For keys with custom definitions, the driver uses stored user configuration data to determine what action to take. This method has the advantage of supporting programmable functions that would be clumsy or impossible to implement using only standard scan codes (such as opening your web browser or email client), and is the method used by most current programmable keyboards. If the driver is not installed, such keyboards function as ordinary keyboards, with special-purpose keys and programmable features disabled.

In our experience, fully programmable keyboards are suitable for "power users" but are likely to confuse casual users. We frequently receive calls from people using such keyboards who have accidentally enabled programming mode and have no idea how to get back into normal mode, or even that they'd done anything to cause the problem. A more subtle problem is that people often program their passwords into the keyboard, which both impairs security and causes support hassles if the password is cleared and the user has forgotten it, as often happens. Programmable keyboards should be reserved for people who are willing to learn to use their features and are aware of the potential security risks.