PS/2 Keyboard

!! How to get keyboard input in protected mode

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

[Kernel loaded|BareBones]
[IDT set up|InterruptsForDummies]
[PIC remapped|Can I remap the PIC?]
IRQ for keyboard unmasked and pointing to your future [keyboard ISR|InterruptServiceRoutines]

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.

!! Okay, then what ?

The keyboard communicates with your computer through a chip called 8042 (on modern system, the functionnality 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 dataport (port 0x60).

From your point of view, things are as easy as <verbatim> 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)

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

} </verbatim>

See http://www.win.tue.nl/~~aeb/linux/kbd/scancodes.html for hints about how you should interprete 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): <verbatim>

  int temp = inportb(0x61);
  outportb(0x61,temp | 0x80);  // disable
  outportb(0x61,temp & 0x7F);  // and reenable

</verbatim>

!! Ctrl, Alt, shift, etc.

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 <verbatim>

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

</verbatim>

Similarily, 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 interprete character 'A' differently based on whether the 'SHIFT' key is up or down, you have first to _remember_ the state of the shift key.

<verbatim> 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);

} </verbatim>

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.

!! What's that E0 scancode i get all the time ?

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

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.

<verbatim> 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);

} </verbatim>

!! What should i do with 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.

!! How can i support 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 internationnal 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 ...

!Todo: Add info on: scan codes, changing led lights, handle shift/caps etc,etc... Maybe change name to "Keyboard programming" or similar, since it's not only about getting a key.

PS/2 Keyboard

Navigation menu

Search