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 "key state flags" are maintained by the keyboard driver in memory, not by any hardware.
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?
These keys would be the left GUI and right GUI keys - have a look at a (US) windows keyboard next to the alt keys.
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
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).
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.
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):
; Bit/s Description
; 0 to 7 ASCII value of keypress
; 8 to 15 Key code
; 16 Scroll lock is on if set
; 17 Number lock is on if set
; 18 Capitals lock is on if set
; 19 to 23 Unused/reserved
; 24 Left shift key is also pressed if set
; 25 Right shift key is also pressed if set
; 26 Left alt key is also pressed if set
; 27 Right alt key is also pressed if set
; 28 Left control key is also pressed if set
; 29 Right control key is also pressed if set
; 30 Key is repeat key if set
; 31 Key was released if set
; 32 to 63 UNICODE character
The steps my keyboard driver's IRQ handler take are:
- read the byte from the keyboard
- if it's an "ACK", clear the "last sent" data and EOI.
- if it's a "retry", resend the "last sent" data (unless the same data has been sent to the keyboard more than 3 times) and EOI.
- if it's a "BAT", reset the typematic rate and keyboard LEDs and EOI
- convert the received byte into a "key code" (I define a unique 8 bit key code for each key)
- if the key code is "caps lock", "scroll lock" or "numb lock", set the keyboard LEDs
- set (if make) or clear (if break) a flag in the key state table corresponding to the key code
- set the key code and pressed/released flag in the keypress packet
- set the other flags in the keypress packet
- use the keypress packet to determine the ASCII character (if any) and set it in the keypress packet
- use the keypress packet to determine the UNICODE character (if any) and set it in the keypress packet
- send a message containing the keypress packet to the user interface code