Keyboard scancodes HOWTO

[XMIT]

Keyboard scancodes, by Andries Brouwer
https://www.win.tue.nl/~aeb/linux/kbd/scancodes.html

I stumbled upon this while reading this link from Hacker News: The little book about OS development by Erik Helin and Adam Renberg. http://littleosbook.github.io/.

Skimming through it, this is a nice introduction on AT scan codes for anyone looking to hack on their keyboard's firmware or write their own.

[Vizir]

Nice! Very useful.

Sent from my Nexus 6P using Tapatalk

[Menuhin]

Thanks for sharing - will look up on how a 'compose key' can be implemented on my keyboards.

By the way, OS development?! Great, I want to see a Lisp machine for the 21st century or one that is written by another functional language, with all the 'bot' trend in OS and businesses.

[gwyn]

Thanks for sharing - will look up on how a 'compose key' can be implemented on my keyboards.

By the way, OS development?! Great, I want to see a Lisp machine for the 21st century or one that is written by another functional language, with all the 'bot' trend in OS and businesses.

I use a software compose key in the place of AltGr on a standard keyboard layout with setxkbmap, but obviously that's missing the main thing you'd want from proper hardware support - the LED.

Andries Brouwer's docs don't mention Compose keys, but the USB HID standard supports Compose LEDs. Most OS developers start out writing PS/2 support because it's a much simpler protocol, but there's no support in PS/2 for any more lights than the three lock lights that the Model M had. Old Sun keyboards with Compose support used a custom protocol.

[vvp]

The current libxkbcommon does not have the code in it to support compose led. The usb keyboard kernel driver supports compose led.
No idea when the compose led was dropped from X. Possibly when they split it to smaller modules.

[XMIT]

Meanwhile I'm wondering how to take advantage of an IEEE 1284 bi-directional parallel port to reduce keyboard latencies. That port can read one 8-bit word every 1 µs. In theory, it could directly scan a 128-position matrix directly every 16 µs, giving a scan rate of 62.5 kHz.

I need to wrap my head around the exact latencies added by a keyboard firmware and USB handling. Particularly with Hall switches sub-1ms latencies should be easily achievable particularly with some direct memory devices.

[DMA]

Meanwhile I'm wondering how to take advantage of an IEEE 1284 bi-directional parallel port to reduce keyboard latencies. That port can read one 8-bit word every 1 µs. In theory, it could directly scan a 128-position matrix directly every 16 µs, giving a scan rate of 62.5 kHz.

IEEE-1394 isochronous mode will work much better. Also there's a bit higher chance to find firewire port in a modern PC than a parallel one.