The Place to Start for Operating System Developers
http://forum.osdev.org/
Code: Select all
volatile unsigned char ScanCode;
...
void irq_01() {
out(0x20, 0x20); // Send EOI
ScanCode = in(0x60);
if((ScanCode & 128) == 128)
// Released
else
// Pressed
}
Have you ever played a computer game, where you' start turning left when you put your finger on the left arrow key and continue turning until you take your finger off the left cursor key?ManOfSteel wrote: I do have another question: are the keyboard break codes important in any way? Do I have to save them for later use?
Thanks for any help.
1- So the makecode will be the same as long as you press the same key, once you release the key, the keyboard driver will read the breakcode key and will stop doing what it was doing (turning in the example). Isn't it?Have you ever played a computer game, where you' start turning left when you put your finger on the left arrow key and continue turning until you take your finger off the left cursor key?
2- So these flags are for shift, ctrl, alt, num-lock, caps-lock and scroll-lock, right? What port(s) should I use to determine what flag is set or cleared?Normally the keyboard driver has a flag for each key, where the flag is set when it's pressed and cleared when it's released. This way software can use these flags to determine which keys are currently pressed. Also it's used to determine if one of the control, alt or shift keys are pressed - "a", "shift+a", "ctrl+a" and "alt+a" usually mean completely different things.
These "key state flags" are maintained by the keyboard driver in memory, not by any hardware.ManOfSteel wrote: 2- So these flags are for shift, ctrl, alt, num-lock, caps-lock and scroll-lock, right? What port(s) should I use to determine what flag is set or cleared?
These keys would be the left GUI and right GUI keys - have a look at a (US) windows keyboard next to the alt keys.ManOfSteel wrote: 3- In a file about the keyboard Scan Codes Set 1, I saw "left GUI" (makecode: E05B, breakcode: E0DB) and "right GUI" (makecode: E05C, breakcode: E0DC). What are these keys?
If this is your IRQ handler then you don't need to check if the keyboard is ready (it wouldn't generate an IRQ unless it was ready).ManOfSteel wrote: 4- In my keyboard driver, I do the following:
* check if the keyboard is ready
* read a key
* check if it's a makecode or breakcode
* in case it's a makecode, I check for shift (left, right),
left ctrl, left alt, extended keys (E0 and E1) or normal keys
* in case it's a normal key, I pass it through the normal
scancode table and end (eoi)
* in case it's a shift key, I check if the keyboard is ready
(if the makecode was sent), I pass it through the shift
scancode table and end (eoi)
* in case it's a ctrl or alt, I treat it as a normal key
(for now).
This depends on your OS and what you want the keyboard driver to do. The keyboard driver for my OS builds a 64 bit "keypress packet" each time a key is pressed or release (and each time a key is repeated when it's held down):ManOfSteel wrote: I didn't implement yet the support for extended keys and breakcode
Till now, is that a decent way to do it? I would be pleased to hear your comments.