PS/2 Keyboard

Protected Mode Keyboard

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 HardWareIrq

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|Forum:7657] 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.

PS/2 Keyboard

Contents

Protected Mode Keyboard

Receiving Input

Scancodes

Escaped Scancodes

Non-Printable Characters

Non-Latin Characters

See Also

Threads

Navigation menu

PS/2 Keyboard

Protected Mode Keyboard

Receiving Input

Scancodes

Escaped Scancodes

Non-Printable Characters

Non-Latin Characters

See Also

Threads

Navigation menu

Search