1. The interrupt handler (written in ASM) requests the scan code from the keyboard
2. The handler calls a C routine that checks and logs the scan code in a couple of ways
The C routine looks like this:
Code: Select all
void kb_handle_keypress (unsigned int scancode) {
// process codes by scancode set
if (scanset == SCANSET_ONE) {
bool breakcode = false;
// was a break code sent?
if (scancode & SETONE_BREAKCODE_MASK) {
breakcode = true;
scancode &= ~SETONE_BREAKCODE_MASK;
}
// was this an extended scancode?
if (scancode == SETONE_EXTENDED_SCANCODE || scancode == SETONE_EXTENDED2_SCANCODE) {
extended = true;
return;
}
// look up the keycode in the keycode maps
unsigned int keycode = KEYCODE_UNKNOWN;
// use the uppercase mapping if caps lock is enabled or shift key is down
if (shift || caps_lock)
keycode = SCANCODE_SET_ONE_UPPER[scancode];
else
keycode = SCANCODE_SET_ONE_LOWER[scancode];
// if the scancode is a shift key, toggle the shift state
if (keycode == KEYCODE_LSHIFT || keycode == KEYCODE_RSHIFT)
shift = (shift) ? false : true;
// if the caps-lock key was released, toggle the caps-lock state
if (keycode == KEYCODE_CAPSLOCK && breakcode) {
caps_lock = (caps_lock) ? false : true;
kb_set_leds (num_lock, caps_lock, scroll_lock);
}
// if a break code was issued, try to place the character in the key queue
if (breakcode) {
// if the key is not something like caps lock, scroll lock, ctrl, etc. add it's char equivalent to the queue
if (!_kb_is_modifier_key (keycode)) {
keybuffer[curpos++] = (unsigned char) keycode;
// on buffer overflow, cut one character from the queue
if (curpos >= KEYBUFFER_MAX)
kb_get_keychar ();
}
}
}
// TODO: Add processing for other scancode sets.
}
Edit: I put this in the theory section because I felt it was related to a design choice. If this is in the wrong forum, I apologize and if it can be moved / should be moved please let me know! Also, this code is not anywhere near finished, so any major flaws are yet to be worked out. I just don't want to keep going with the current design choice if it is a poor one.
). The lowest drivers in the stack manage the most hardware-specific functions, meanwhile the highest drivers manage the most portable and higher-level function. Thus, we can imagine a driver stack with three elements as an example for PS/2 stuff. The lowest driver is the PS/2 Controller driver. It handles device initialization and commands proper to the controller. For each device the driver finds (let's say 2), it "pushes" a new instance of the corresponding driver into the stack. Thus, two new drivers are initialized. Let's say they're the Keyboard driver and the Mouse driver. Both of them are machine independent! The PS/2 Controller driver is the one responsible for coverting scan codes into standard codes. So, once a key is pressed, and the corresponding IRQ redirects to the PS/2 driver, the PS/2 driver computes the standard code. The result is sended as a data packet to the Keyboard driver, which is responsible for advertising the *whole* system about the event. It could also take note of which keys are currently pressed. A bit-array (*not* a byte-array), can help you save memory, with a little computation overhead.
: