Hi,
devchild wrote:I see where this is going
, looks like I need to write a better keyboard_to_ascii() method.
Looks like you need to understand that ASCII is almost completely useless.
If I'm writing a space invaders game and want my spaceship to fire it's main laser weapon while the control key is pressed, which ASCII character do you send for "control pressed" and which ASCII character do you send for "control released"?
What is the ASCII character for "F6", or "PrtScrn", or "alt + q", or "control + 3"?
What are the ASCII characters for this (Hebrew) keyboard:
Think of a keyboard driver as a series of layers. The first layer gets a byte from the keyboard, and doesn't belong in the keyboard driver at all (and belongs in a PS/2 controller driver instead).
The second layer converts those bytes into "key codes" using a state machine. The state machine is needed because some keys send multiple bytes (e.g. pause/break). The "key code" could be a single integer representing where the key is on the keyboard (and at least in theory could literally be the key's location - e.g. "row * 32 + column"). This layer also creates a "flags" that says if the key was pressed or released.
The third layer keeps track of which keys are currently being pressed and which aren't, using (e.g.) a bitfield with 256 bits. If a key is pressed that was already pressed then the key was repeated and wasn't pressed; and this layer would change the "flags" to indicate that (so that the "flags" now contains "pressed/repeated/released").
The fourth layer uses "modifier key data" and "keyboard layout tables"; plus the "key code" and the bitfield of which keys are currently being pressed; to set more flags in the "flags" (based on the "modifier key data") and then use both the "flags" and the "key code" with the "keyboard layout tables" to determine which (hopefully Unicode codepoint) character is involved (if any). Note that there are 2 different types of modifier keys - normal modifier keys (shift, control, alt), and ones that toggle something (capslock, numlock, scrolllock); and for the toggles you need to keep track of its current state and which LED it effects (if any). You can/should assume there may be up to 8 LEDs (where any "modifier toggle key" could effect any of the 8 LEDs). Both the "modifier key data" and the "keyboard layout tables" need to be pure data without any code; because (later on) these will be loaded from disk (and will be different for different keyboard layouts).
The fifth layer sends the entire resulting packet of information to a normal process (e.g. to GUI, to terminal emulator, etc). This "keypress packet" includes the original key code, the Unicode codepoint (if any), plus the "flags". The "flags" contains the pressed/repeated/released (from 2nd and 3rd layer), plus one bit per modifier key (from 4th layer).
You might also want to provide a way for software to ask the driver if a key is currently being held down (e.g. "bool isDown(int keycode)"), and to ask the driver what each key looks like (e.g. "string getDescription(keycode)"). To understand this, imagine a game that uses the key at "row=1, column=2" for forward, and the 3 keys at "row = 2, column = 1 to 3" for left/backward/right. Normally it doesn't care what these keys are (only the key's location/key code matters); but in its "keyboard settings" menu (and/or in its help system) it might want to display which keys the player should use to play the game - for a QWERTY keyboard it'd want to display "WASD", for an AZERTY keyboard it'd want to display "ZQSD", for Dvorack it'd want to display ",AOE", for French BEPO it'd want to display "EAUI", for Turkish F it would want to display "GUIE", etc. If the game can ask the keyboard driver what to display it makes things so much easier.
Cheers,
Brendan
