F
Franc Zabkar
That's not how PC keyboards work, at least not according to the
original IBM standard.
The keyboard sends a "scan code" that identifies the keypress.
See http://www.users.on.net/~fzabkar/MSKeyLog.TXT
When the NumLock key is pressed (make), the keyboard sends a "0x45"
code to the keyboard controller on the motherboard. When the NumLock
key is released (break), the keyboard sends "0xC5" (= 0x45 + 0x80).
The keyboard does not maintain a record of the numlock state. That is
the job of the OS. The OS responds to the NumLock keypress by toggling
its own NumLock status, and then sends a command to the keyboard to
either turn on or off the NumLock LED.
When you press a key, the keyboard sends the scan code for that key,
not its ASCII code. For example, let's say you have a keyboard with
100 keys. The "A" key on a US keyboard might be key #52, whereas the
same physical key position on a Japanese keyboard will be something
else entirely. However, if the keyboards are electronically identical,
then key #52 will have the same scan code for both keyboards. The OS
determines the ASCII code by looking up the scan code in the US or
Japanese key maps.
Similarly, let's say you have pressed the Home/7 key on the numeric
keypad. The keyboard transmits the same scan code for either Home or
Num 7, but the OS determines how to interpret the key by referring to
the OS NumLock flag.
To illustrate this behaviour, I have an AT style keyboard connected to
two PCs via a passive KVM box. If the second PC is powered off, then
switching the keyboard to PC #2 and back to PC #1 effectively power
cycles it. If the CapsLock and NumLock LEDs are both on at the start,
then they will be turned off after a power cycle. However, pressing
any alphabet key or numeric keypad key still produces uppercase and
numeric characters, so it is clear that the OS is remembering the
NumLock and CapsLock status, not the keyboard.
Having said the above, I have no idea whether the PC/AT specification
is valid for your keyboard.
- Franc Zabkar