PS/2 Keyboard

This article is a quick merger of two previous articles (the old Keyboard Controller article and the old PS2 Keyboard article) and may not be complete. --Troy Martin 14:49, 2 April 2009 (UTC)

The Keyboard Controller

The Keyboard Controller (KBC) is located on the mainboard. The name is misleading because the Controller does more then controlling the communication with the hardware on the keyboard.

In the early days the controller was a single chip (8042). As of today it is part of the Advanced Integrated Peripheral.

Functions of the KBC

• Controlling one or two PS/2 connectors OR one 5pin DIN connector
• CPU Reset
• Enable/Disable the A20-Gate
• Controlling the PC Speaker together with the Programmable Interval Timer.

KBC Types

Overview of the AT-KBC

Overview of the PS/2-KBC

There are two kinds of KBCs that somewhat differ from each other. The first KBC is the AT-KBC introduced with the AT-System. The second one is the PS/2-KBC introduced with the PS/2-System.

The ancestor of the AT-System the XT-System used the Programmable Peripheral Interface (PPI) for comparable tasks.

USB Legacy Support

By modern standards you will find many PCs bundled with USB input devices. Some PCs may not even have PS/2 connectors at all. To remain compatible with old software, the mainboard emulates USB Keyboards and Mouses as PS/2 devices. This is called USB Legacy Support.

Because the implementation differ by manufacturer and mainboard there are flaws and sometimes even bugs:

• Some emulation layers also handle the communication with the real PS/2 connectors regardless of any connected USB device. So maybe not all capabilities of the PS/2 connectors and devices can be used.
  For example extended mouse modes needed to use the scroll wheel won't work or the keyboard only works on the first PS/2 connector and the mouse only on the second connector.

• The SMM BIOS that's providing the PS/2 USB Legacy Support may not support extended memory techniques or the Long mode and therefore cause system crashes.

The follow part needs to to be confirmed!
This emulation layer is disabled as soon as the USB Chipset gets initiated by software. (The mainboard knows the OS has USB drivers and therefore can communicate with the devices directly)

Simple keyboard handler for real mode

This is an example how to use the keyboard in real mode. The Scancode for pressed and released keys is displayed on the screen.

The source works with NASM and FASM. You can copy the output file to the boot sector of a floppy or use it with an Emulator.

use16
org 0x7C00

;Disable interrupts
cli

;set DS to 0
xor  ax, ax
push ax
pop  ds

;The IRQ1 (keyboard) is mapped on interrupt 9 by default
;Now we write the address of the handler in the Interrupt descriptor table (IDT)
mov word[ds:(9*4)  ], keyboard_handler    ;Offset
mov word[ds:(9*4)+2], 0                   ;Segment

;Enable interrupts
sti

jmp $

;This handler gets called each time a IRQ1 is triggered by the keyboard
keyboard_handler:
  pusha
 
  ;read scancode
  in  al, 0x60
 
  ;Here you can do with the scancode whatever you like.
  ;For example converting it to another keyboard layout or test for special keys and trigger a reboot
  
  call write_byte_as_hex
  mov  al, '|'
  call bios.write_char
 
  ;Now we tell the first PIC that the IRQ is handled
  mov al, 0x20
  out 0x20, al
 
  popa
iret
 
 
;Input: al = char
bios.write_char:
  pusha
  mov  ah, 0x0E
  int  0x10
  popa
ret
 
hex_chars: db '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C', 'D', 'E', 'F'

;This is a small function to write a value on the screen
;Input: al = byte
write_byte_as_hex:
  pusha
  and  ax, 0xFF
  push ax
  mov  bx, ax
  shr  bx, 4
  mov  al, [hex_chars+bx]
  call bios.write_char
  pop  bx
  and  bx, 0xF
  mov  al, [hex_chars+bx]
  call bios.write_char
  popa
ret
 
times 510-($-$$) db 0
dw 0xAA55

CPU Reset

To trigger a CPU Reset (No matter what state the CPU currently has) you have to write the value 0xFE to the Outputport.

;Wait for a empty Input Buffer
wait1:
in   al, 0x64
test al, 00000010b
jne  wait1

;Send 0xD1 to the KBC. This is the command to write the Outputport.
mov  al, 0xD1
out  0x64, al

;Wait for a empty Input Buffer
wait2:
in   al, 0x64
test al, 00000010b
jne  wait2

;Now we can write the new value (0xFE) for the Outputport to port 0x60
mov  al, 0xFE
out  0x60, al

Protected Mode Keyboard Driver

First of all you should have this steps ready in your OS:

• Kernel loaded
• IDT set up
• PIC remapped
• IRQ for keyboard unmasked and pointing to your future keyboard ISR

Read all about IRQ's and PIC's at Interrupts

To get keyboard input you read the port 0x60 and save the translated scan code to a buffer.

Receiving Input

The keyboard communicates with your computer through a chip called 8042 (on modern system, the functionality of that chip is emulated by the chipset). Any key press or key release leads to the transmission of a scancode to the 8042 which then raises IRQ1 and makes the scancode available in its data port (port 0x60).

From your point of view, things are as easy as

void KeyboardIsr()
{
   byte new_scan_code = inportb(0x60);

   /* Do something with the scancode.
    * Remember you only get one byte of the scancode each time the ISR is invoked.
    * (Though most of the times the scancode is only one byte.) 
    */

   /* Acknowledge the IRQ, pretty much tells the PIC that we can accept >=priority IRQs now. */
   outportb(0x20,0x20);
}

See http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html for hints about how you should interpret what you get from the keyboard.

Note that if you repeatedly read the port 0x60 without waiting for another IRQ, you'll read the same byte again. That's the 'normal' behaviour of keyboard controller, but if that doesn't suit your needs, you can still "acknowledge" the scancode by quickly disabling and re-enabling the keyboard at the PPI (Programmable Peripheral Interface):

int temp = inportb(0x61);
outportb(0x61,temp | 0x80);  /* Disable */
outportb(0x61,temp & 0x7F);  /* Re-enable */

Scancodes

The keyboard only reports keystrokes. That means it makes no difference between an uppercase 'A' and a lowercase 'a' when you hit the key. The trick is that you'll get two kind of scancodes: make codes and break codes, depending on whether you hit or release the key. For instance if you type an uppercase 'A', you'll get

0x2A	(make shift)
0x1E	(make A)
0x9E	(break A)
0xAA	(break shift)

Similarly, when you type 'hi' with the CTRL key hold down, your keyboard sends the codes 1d, 23, a3, 17, 97, 9d to the CPU. That means if you want to interpret character 'A' differently based on whether the 'SHIFT' key is up or down, you have first to remember the state of the shift key.

char lowercase[256] = {0x1E:'a'};
char uppercase[256] = {0x1E:'A'};

unsigned shift_state = 0;

void KeyboardIsr()
{
   byte new_scan_code = inportb(0x60);

   switch(new_scan_code) {
       case 0x2a: 
           shift_state = 1; 
           break;

       case 0xaa: 
           shift_state = 0;
           break;

       default:
          if (new_scan_code & 0x80) {
             /* Ignore the break code */
          } else {
             new_char =(shift_state ? uppercase:lowercase)[new_scan_code];
             /* Do something with new_char. */
          }
          break;
    }

    outportb(0x20,0x20);
}

The arrays lowercase and uppercase are the conversion arrays, also called keyboard map. A different keyboard language will lead to different keyboard maps, so you're welcome to provide an API call that will allow the change of that map. You might also want an alternate map for characters composed with ~[ALTgr] key hold down or a wchar_t based map that will allow you to map a keystroke directly to Unicode characters.

Escaped Scancodes

Several keys on your keyboard have a two-bytes scan code (they're said to be escaped scancodes). All those codes start with 0xe0 and are then followed by the 'real' scancode, which means when receiving scancode 0xe0, you should just store the info and wait for the next scancode to know what key even actually occurred.

If you look at the list of escaped scancodes on http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html, you'll note that none of them correspond to a 'printable' character.

unsigned shift_state = 0;
unsigned escaped=0;

void KeyboardIsr()
{
   unsigned new_scan_code = inportb(0x60);
   if (escaped) new_scan_code += 256;
   switch(new_scan_code) {
   case 0x2a: shift_state = 1; break;
   case 0xaa: shift_state = 0; break;
   case 0xe0: escaped = 1; break;
   default:
      if (new_scan_code & 0x80) {
         // ignore the break code
      } else {
         new_char=(shift_state?uppercase:lowercase)[new_scan_code];
         // do something with new_char
      } 
  break;

  outportb(0x20,0x20);
}

Non-Printable Characters

ToDo: think about it. We can however already say that they should follow the same 'datapath' as regular characters: we want cursor displacements, regular keytypes and commands (such as CTRL+S) to be delivered to the application in the same order the user typed them, and the best way to achieve this is to ensure they're delivered through the same data stream.

Non-Latin Characters

In case you'd like to write an OS with support of Arabic, Kanji or whatever, you'll at least need support for Unicode. We had a thread about loading Arabic fonts on the forum, which you might like to look at.

Anyway, please consider the following: even if your userbase is mainly Arabic/Japanese/whatever, your guru base is likely to be international and to prefer messages about "queue" or "thread" than about whatever the translation might look like, so English might be preferred for "behind the scene" stuff.

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
• Keyboard scancodes - A complete reference on all scancodes you might encounter.