How can I write a good keyboard driver?
I know how to register a key function in the IDT buf I don't know what's the best way to save the recived key-codes.
Should I save them in a buffer?? Should I save them in a single variable so it is updated every keypress.
And how should the functions look like, which return the keys.
Keyboard driver
Re:Keyboard driver
I think it is good to record each key into a key buffer. This buffer is a queue and functions like getchar(), getc() and so on will pick out the first entry of this queue. So you have something like:
In this case, keyboard_handler() would be called by your ISR.
This is just one way, it is just a design questions, but I think that many OSes (and many guys here) use this way.
Code: Select all
queue_t queue;
void keyboard_handler(void)
{
int code;
char key;
code = scan_keyboard(); /* Get scancode */
key = map_key(code); /* Map scancode to ASCII */
insert_into_queue(&queue, key);
}
This is just one way, it is just a design questions, but I think that many OSes (and many guys here) use this way.
Re:Keyboard driver
single key variable can be used to store the converted key. keyboard 'q' will be used by many high end OSes. for a beginner, a single variable is enough.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Keyboard driver
there are actually more things that you may want to take into account:
- many keyboard layout exists (qwerty, azerty, qwertz ...), so it is wise to keep that in mind and leave a 'hook' for reporgramming the currently used layout, either through a module facility, or by simply having a 'setkeymap' system call.
- many character encoding exists too (ASCII, UTF, Unicode, etc), so you might want to have a 2 stages key converters (for instance first mapping from scancodes to unicode and then from unicode to whatever the console needs).
- some keys are used as 'modifiers' (shift, ctrl and alt, to mention those only). Pressing on such a key does not immediately generate an ASCII code, but instead modifies the internal state of the system so that other keys will be handled differently... This somehow states for one "shifted", one "non-shifted" and one "alt" translation table...
- finally, you need a way to report keystrokes that do not translate into characters (for instance ALT+F4 and CTRL+ALT+DEL ?)
- many keyboard layout exists (qwerty, azerty, qwertz ...), so it is wise to keep that in mind and leave a 'hook' for reporgramming the currently used layout, either through a module facility, or by simply having a 'setkeymap' system call.
- many character encoding exists too (ASCII, UTF, Unicode, etc), so you might want to have a 2 stages key converters (for instance first mapping from scancodes to unicode and then from unicode to whatever the console needs).
- some keys are used as 'modifiers' (shift, ctrl and alt, to mention those only). Pressing on such a key does not immediately generate an ASCII code, but instead modifies the internal state of the system so that other keys will be handled differently... This somehow states for one "shifted", one "non-shifted" and one "alt" translation table...
- finally, you need a way to report keystrokes that do not translate into characters (for instance ALT+F4 and CTRL+ALT+DEL ?)