4 ms·

A brief history of keyboard encoding (2023)

64 points by fanf2 3y ago

jsheard 3y ago
Split ergonomic keyboards have wrapped all the way around to the simplest possible solution - they have so few keys that each one can simply be connected directly to its own dedicated pin on the microcontroller, no diodes or matrix scanning required. e.g. the Ferris Sweep: https://github.com/davidphilipbarr/Sweep https://github.com/davidphilipbarr/Sweep That has 17 keys per side, which is the most you can do with the 18 GPIOs broken out by the popular Pro Micro modules, but with something like the RP2040 you could scale it up to 29 keys per side if desired.
- Karliss 3y ago
  No diodes, no matrix all you need is two microprocessors (in addition to your computer) communicating with each other over custom serial protocol. Definitely the simplest solution.
  - jsheard 3y ago
    Every modern keyboard uses a general purpose MCU anyway (formerly AVR, now usually ARM) so it's not like they're adding any complexity by using MCUs, and regardless of how the key scanning is implemented you would still want a programmable processor to support all of the layers and macros required to make such a small keyboard practical. Some early iterations of split keyboards did use a parallel bus between the halves instead, which allowed them to have a single matrix spanning both sides which was read by a single MCU, but that went out of style since the cables were unwieldy and MCUs are cheap. Now they all use two MCUs linked over serial, or wireless.
    - kps 3y ago
      Or an MCU and a GPIO expander like a 23017 over I²C.
      - crote 3y ago
        GPIO expanders are surprisingly slow and quite expensive. A two-MCU solution is almost always the better option.
  - mananaysiempre 3y ago
    Cost is definitely a part of the definition of simplicity in board design; so is ease of development. So yes, it does feel perverse but just sticking a microcontroller in it is often the simplest solution to a low-speed digital problem. Somebody had to design that microcontroller and it probably has a bunch of errata that basically say a quarter of it doesn’t work, but that’s already done and they are not that much more expensive (if at all) than a 555 timer. It probably isn’t even losing on power consumption. Simplicity is weird.
- klysm 3y ago
  That’s how I implement my keyboards. Much smaller part count and way easier to code
deleted 3y ago
[deleted]
cbolton 3y ago
Lot's of interesting information, but this part seems inaccurate: "Matrix scan [is in] use in all keyboards today. [...] matrix scan keyboards not only allow for an unlimited number of overlapping keystrokes, but they can correctly identify each and every simultaneously-held key" I found the hard way that this is not true. Took me a while to figure out why some weird keyboard shortcuts were not working only to find that it's a hardware limitation. Here's a simple test for your laptop keyboard: try LeftShift+RightShift+Q and see if it prints anything. Repeat with the other letters of the alphabet. In my case I get nothing for several letters such as X, T and M.
- Majromax 3y ago
  Matrix-scan keyboards allow for an unlimited number of overlapping keystrokes, but that allowance requires per-key diodes to prevent ghosting. Inexpensive keyboards often forego the per-key diodes in favour of cheaper/thinner construction, and to prevent phantom inputs the controller registers nothing when the matrix scan shows keypresses that might be the result of ghosting.
  - cbolton 3y ago
    Aha so I guess the article is technically correct!
- Findecanor 3y ago
  > Here's a simple test for your laptop keyboard: try LeftShift+RightShift+Q and see if it prints anything. Repeat with the other letters of the alphabet. In my case I get nothing for several letters such as X, T and M. Microsoft has published a table of key combinations that are required to work in Windows, and it does not include combos of two modifiers of the same type .. with one exception: Both Windows keys have to work together. (You'd not often find a laptop keyboard that has two Windows keys though) There's otherwise a convention when constructing (diode-less) keyboards to put the modifier keys outside the keyboard matrix altogether so as to guarantee that you'd avoid key-combo collisions with them. I.e. each of the Control, Shift, Alt/Option, Windows/Command/Super keys would get its own dedicated GPIO pin on the controller. BTW. On the old Amiga platform, the rollover issue was handled in a prudent way: Keyboards that did not have NKRO all had a standard keyboard matrix that was published in a reference manual which software developers could consult to figure out which key combos that were viable and which were not. Also here the modifier keys were outside the matrix.
maherbeg 3y ago
There's also this new result for diodeless keyboards with many more keys despite limited GPIO: https://www.reddit.com/r/ErgoMechKeyboards/comments/1berag2/new_diodeless_keyboards_with_more_keys/ https://www.reddit.com/r/ErgoMechKeyboards/comments/1berag2/...
- crote 3y ago
  Note that it doesn't provide NKRO - it's just a fancy way reducing the likelihood of key collisions, so pretty much the same thing cheap diodeless keyboards have been doing for ages.
javier_e06 3y ago
Great article. I worked a while ago for a company that make KVM switches for data center. We had to validate keyboard layouts for many locations. In a Linux terminal one can type $xev And capture the events coming from the keyboard. Press letter "a" KeyPress event, serial 37, synthetic NO, window 0x1e00001, root 0x7b2, subw 0x0, time 58826694, (-660,975), root:(1171,2000), state 0x10, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XmbLookupString gives 1 bytes: (61) "a" XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x1e00001, root 0x7b2, subw 0x0, time 58826840, (-660,975), root:(1171,2000), state 0x10, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XFilterEvent returns: False Cool stuff.
rrgok 3y ago
Asking here, in the hope that someone can explain to me the following. I genuinely want to understand it. What is the historical reason for having the OS manage the keyboard layout instead of the keyboard itself? If I tap on the key Z, it should, no matter what the OS wants, send Z, and the OS should receive and "print" Z. Why should the OS decide that sometimes Z becomes Y and other times Z (obviously depending on the layout)? The same question applies to missing F keys (F19..?). Why should the OS limit itself to what keys it receives? I believe USB can transmit enough keycodes to include all available keys on all platforms. The same applies to capital letters. Why is there only one keycode for "a" and "A"? The keyboard should send KC_SHFT+KC_A to let the OS know it is a capitalized A. Couldn't there just be another keycode for that? Why the OS should care if I pressed the shift or not? It should receive capital A. Isn't it the keyboard job to send the right keycode for whatever combination I tap? We can run through USB gigabytes of 4K videos, but somehow we cannot have a separate keycode for each available letter in the world? Heck, QMK can send MIDI Notes through your keyboard, but somehow we cannot have a separate key for each letter in the world? I don't believe that nowadays it is a problem of memory or processing power. I seriously believe that I'm missing something behind this architecture. Hope someone can explain the drawback in my way of thinking.
- mrb 3y ago
  In general, in electronics, when a firmware is involved and communicates with a higher-level software, it's almost always better to make the firmware as simple as possible, as dumb as possible, because the firmware is more difficult and tedious to update than the higher-level software, and it makes the hardware/firmware simpler and cheaper to design. For example say we followed your suggestion and the keyboard had to be responsible for key mapping. This means it would probably need non-volatile memory for saving the keymap in use (or it would forget it when unplugged.) The extra component adds a bit more cost, and increases the chances of hardware failure. If you want to forego NV memory, the software would have to be responsible for initializing the keymap every time the keyboard is plugged in. But if the software is choosing which keymap to use anyway, then technically it's simpler to let the key mappping happen in software and not firmware.
- deleted 3y ago
  [deleted]
DavidVoid 3y ago
This article gives me an excuse to mention my favorite obscure old keyboard switch type: the acoustic keyboard switch. Back in the 80s when electronics were expensive, someone figured out that you could detect all key-presses on a keyboard with just a couple of microphones. There was no wiring to any of the key switches, instead there was a long metal bar underneath the keyboard with a microphone on each side. Pressing a key made a little metal hammer hit that bar, and the difference of arrival between the two microphones was then used to figure out which key had been pressed. Here's a presentation from Keycon 2014 about it (starts at 1:46:01, description of how it works starts at 1:50:30): https://www.youtube.com/live/AvszDsr1js8?t=6361 https://www.youtube.com/live/AvszDsr1js8?t=6361

64 points by fanf2 3y ago

Split ergonomic keyboards have wrapped all the way around to the simplest possible solution - they have so few keys that each one can simply be connected directly to its own dedicated pin on the microcontroller, no diodes or matrix scanning required. e.g. the Ferris Sweep: https://github.com/davidphilipbarr/Sweep https://github.com/davidphilipbarr/Sweep That has 17 keys per side, which is the most you can do with the 18 GPIOs broken out by the popular Pro Micro modules, but with something like the RP2040 you could scale it up to 29 keys per side if desired.

Karliss 3y ago
No diodes, no matrix all you need is two microprocessors (in addition to your computer) communicating with each other over custom serial protocol. Definitely the simplest solution.
- jsheard 3y ago
  Every modern keyboard uses a general purpose MCU anyway (formerly AVR, now usually ARM) so it's not like they're adding any complexity by using MCUs, and regardless of how the key scanning is implemented you would still want a programmable processor to support all of the layers and macros required to make such a small keyboard practical. Some early iterations of split keyboards did use a parallel bus between the halves instead, which allowed them to have a single matrix spanning both sides which was read by a single MCU, but that went out of style since the cables were unwieldy and MCUs are cheap. Now they all use two MCUs linked over serial, or wireless.
  - kps 3y ago
    Or an MCU and a GPIO expander like a 23017 over I²C.
    - crote 3y ago
      GPIO expanders are surprisingly slow and quite expensive. A two-MCU solution is almost always the better option.
- mananaysiempre 3y ago
  Cost is definitely a part of the definition of simplicity in board design; so is ease of development. So yes, it does feel perverse but just sticking a microcontroller in it is often the simplest solution to a low-speed digital problem. Somebody had to design that microcontroller and it probably has a bunch of errata that basically say a quarter of it doesn’t work, but that’s already done and they are not that much more expensive (if at all) than a 555 timer. It probably isn’t even losing on power consumption. Simplicity is weird.
klysm 3y ago
That’s how I implement my keyboards. Much smaller part count and way easier to code

deleted 3y ago

[deleted]

cbolton 3y ago

Lot's of interesting information, but this part seems inaccurate: "Matrix scan [is in] use in all keyboards today. [...] matrix scan keyboards not only allow for an unlimited number of overlapping keystrokes, but they can correctly identify each and every simultaneously-held key" I found the hard way that this is not true. Took me a while to figure out why some weird keyboard shortcuts were not working only to find that it's a hardware limitation. Here's a simple test for your laptop keyboard: try LeftShift+RightShift+Q and see if it prints anything. Repeat with the other letters of the alphabet. In my case I get nothing for several letters such as X, T and M.

Majromax 3y ago
Matrix-scan keyboards allow for an unlimited number of overlapping keystrokes, but that allowance requires per-key diodes to prevent ghosting. Inexpensive keyboards often forego the per-key diodes in favour of cheaper/thinner construction, and to prevent phantom inputs the controller registers nothing when the matrix scan shows keypresses that might be the result of ghosting.
- cbolton 3y ago
  Aha so I guess the article is technically correct!
Findecanor 3y ago
> Here's a simple test for your laptop keyboard: try LeftShift+RightShift+Q and see if it prints anything. Repeat with the other letters of the alphabet. In my case I get nothing for several letters such as X, T and M. Microsoft has published a table of key combinations that are required to work in Windows, and it does not include combos of two modifiers of the same type .. with one exception: Both Windows keys have to work together. (You'd not often find a laptop keyboard that has two Windows keys though) There's otherwise a convention when constructing (diode-less) keyboards to put the modifier keys outside the keyboard matrix altogether so as to guarantee that you'd avoid key-combo collisions with them. I.e. each of the Control, Shift, Alt/Option, Windows/Command/Super keys would get its own dedicated GPIO pin on the controller. BTW. On the old Amiga platform, the rollover issue was handled in a prudent way: Keyboards that did not have NKRO all had a standard keyboard matrix that was published in a reference manual which software developers could consult to figure out which key combos that were viable and which were not. Also here the modifier keys were outside the matrix.

maherbeg 3y ago

There's also this new result for diodeless keyboards with many more keys despite limited GPIO: https://www.reddit.com/r/ErgoMechKeyboards/comments/1berag2/new_diodeless_keyboards_with_more_keys/ https://www.reddit.com/r/ErgoMechKeyboards/comments/1berag2/...

crote 3y ago
Note that it doesn't provide NKRO - it's just a fancy way reducing the likelihood of key collisions, so pretty much the same thing cheap diodeless keyboards have been doing for ages.

javier_e06 3y ago

Great article. I worked a while ago for a company that make KVM switches for data center. We had to validate keyboard layouts for many locations. In a Linux terminal one can type $xev And capture the events coming from the keyboard. Press letter "a" KeyPress event, serial 37, synthetic NO, window 0x1e00001, root 0x7b2, subw 0x0, time 58826694, (-660,975), root:(1171,2000), state 0x10, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XmbLookupString gives 1 bytes: (61) "a" XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x1e00001, root 0x7b2, subw 0x0, time 58826840, (-660,975), root:(1171,2000), state 0x10, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XFilterEvent returns: False Cool stuff.

rrgok 3y ago

Asking here, in the hope that someone can explain to me the following. I genuinely want to understand it. What is the historical reason for having the OS manage the keyboard layout instead of the keyboard itself? If I tap on the key Z, it should, no matter what the OS wants, send Z, and the OS should receive and "print" Z. Why should the OS decide that sometimes Z becomes Y and other times Z (obviously depending on the layout)? The same question applies to missing F keys (F19..?). Why should the OS limit itself to what keys it receives? I believe USB can transmit enough keycodes to include all available keys on all platforms. The same applies to capital letters. Why is there only one keycode for "a" and "A"? The keyboard should send KC_SHFT+KC_A to let the OS know it is a capitalized A. Couldn't there just be another keycode for that? Why the OS should care if I pressed the shift or not? It should receive capital A. Isn't it the keyboard job to send the right keycode for whatever combination I tap? We can run through USB gigabytes of 4K videos, but somehow we cannot have a separate keycode for each available letter in the world? Heck, QMK can send MIDI Notes through your keyboard, but somehow we cannot have a separate key for each letter in the world? I don't believe that nowadays it is a problem of memory or processing power. I seriously believe that I'm missing something behind this architecture. Hope someone can explain the drawback in my way of thinking.

mrb 3y ago
In general, in electronics, when a firmware is involved and communicates with a higher-level software, it's almost always better to make the firmware as simple as possible, as dumb as possible, because the firmware is more difficult and tedious to update than the higher-level software, and it makes the hardware/firmware simpler and cheaper to design. For example say we followed your suggestion and the keyboard had to be responsible for key mapping. This means it would probably need non-volatile memory for saving the keymap in use (or it would forget it when unplugged.) The extra component adds a bit more cost, and increases the chances of hardware failure. If you want to forego NV memory, the software would have to be responsible for initializing the keymap every time the keyboard is plugged in. But if the software is choosing which keymap to use anyway, then technically it's simpler to let the key mappping happen in software and not firmware.
deleted 3y ago
[deleted]

DavidVoid 3y ago

This article gives me an excuse to mention my favorite obscure old keyboard switch type: the acoustic keyboard switch. Back in the 80s when electronics were expensive, someone figured out that you could detect all key-presses on a keyboard with just a couple of microphones. There was no wiring to any of the key switches, instead there was a long metal bar underneath the keyboard with a microphone on each side. Pressing a key made a little metal hammer hit that bar, and the difference of arrival between the two microphones was then used to figure out which key had been pressed. Here's a presentation from Keycon 2014 about it (starts at 1:46:01, description of how it works starts at 1:50:30): https://www.youtube.com/live/AvszDsr1js8?t=6361 https://www.youtube.com/live/AvszDsr1js8?t=6361