Fix bug where Pause/Break key scancode is converted to Ctrl-NumLock.

[TomAwezome]

No description provided.

[GutPuncher]

https://wiki.osdev.org/PS/2_Keyboard#Scan_Code_Set_1
https://wiki.osdev.org/PS/2_Keyboard#Scan_Code_Set_2

Scancode Set 2:

• Pause/Break
  • 0xE1 0x14 0x77 0xE1 0xF0 0x14 0xF0 0x77
• LeftCtrl (Pressed)
  • 0x14
• NumLock (Pressed)
  • 0x77
• LeftCtrl (Released)
  • 0xF0 0x14
• NumLock (Released)
  • 0xF0 0x77
• LeftCtrl-NumLock (Pressed)
  • 0x14 0x77
• LeftCtrl-NumLock (Released)
  • 0xF0 0x14 0xF0 0x77

[GutPuncher]

It appears Zeal is interpreting Pause/Break as Ctrl-NumLock because of either the starting three bytes matching LeftCtrl-NumLock Pressed, or the latter four bytes matching LeftCtrl-NumLock Released. Though the specific bytes are different for Scan Code 1, both sets have matching byte values in the scancodes like this for these keys. The only distinguishing factor is that the isolated Pause/Break code starts with 0xE1 and divides the duplicates via another 0xE1. The code that processes 0xE1 bytes in the keyboard driver scan code parsing/scancode-to-keyname logic may need to be reviewed

[GutPuncher]

https://github.com/Zeal-Operating-System/ZealOS/blob/master/src/Kernel/SerialDev/Keyboard.ZC

See:

• ScanCode2Char
• ScanCode2KeyName
• KbdBuildSC
• KbdPacketRead
• KbdHandler

[GutPuncher]

From the OSDev Wiki link above:

Note that scancodes with extended byte (E0) generates two different interrupts: the first containing the E0 byte, the second containing the scancode

The mentioned functions have different mechanisms for handling this 0xE0 "extended byte", but the odd 0xE1 of Pause/Break is likely being dropped/skipped/incorrectly matched, and the rest of its bytes matching up to the next closest scancode. An additional integration for factoring in the Pause/Break scancode similar to how 0xE0 bytes are handled may be needed to resolve this bug