[HN Gopher] A brief history of keyboard encoding (2023)
___________________________________________________________________
A brief history of keyboard encoding (2023)
Author : fanf2
Score : 54 points
Date : 2024-04-08 10:42 UTC (12 hours ago)
(HTM) web link (kbd.news)
(TXT) w3m dump (kbd.news)
| jsheard wrote:
| 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
|
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Or an MCU and a GPIO expander like a 23017 over I2C.
| crote wrote:
| GPIO expanders are surprisingly slow and quite expensive.
| A two-MCU solution is almost always the better option.
| mananaysiempre wrote:
| 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 wrote:
| That's how I implement my keyboards. Much smaller part count
| and way easier to code
| cbolton wrote:
| 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 wrote:
| 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 wrote:
| Aha so I guess the article is technically correct!
| Findecanor wrote:
| > 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.
| cbolton wrote:
| Thanks for the extra information. I guess CapsLock is not
| given this special treatment? (my actual issue was when using
| CapsLock as a Ctrl key).
| dcminter wrote:
| Thinkpads used to (?) sound an obnoxiously aggressive beep if
| you hit this limit. It was a nasty square wave at maximum
| volume and always made me jump. In later models you could
| disable it in the BIOS. I'm not sure if that's still something
| they do, or if it's gone the way of the Thinklight and the
| drainage holes!
| maherbeg wrote:
| There's also this new result for diodeless keyboards with many
| more keys despite limited GPIO:
| https://www.reddit.com/r/ErgoMechKeyboards/comments/1berag2/...
| crote wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| mrob wrote:
| The OS needs to track whether shift is pressed anyway, because
| shift is also used as a modifier key for mouse inputs (e.g.
| selecting text with shift+drag). If the keyboard also keeps
| track of it, it's duplicating work and introducing the
| possibility of de-synchronization.
| Findecanor wrote:
| 1. To simplify manufacturing for different markets that have
| different keyboard layouts. Most keyboard controllers in the
| world are not programmable but are fixed-function, with the
| matrix defined by the chip's manufacturer even.
|
| 2. For multilingual users. Allows them to switch keyboard
| layout easily. Even many European programmers switch to US-ANSI
| to get easier access to programming-language symbols such as ~
| ^ [ { } ] , and back to type in their native layout which could
| have other symbols on those physical keys.
| samatman wrote:
| A common microcontroller board for building hobby mechanical
| keyboards is the Teensy 4. This uses an ARM Cortex M7 with 1MB
| RAM, 2MB flash, running at 600MHz.
|
| In 1986, an exceptional machine like the IRIS 2000 ran at
| 10MHz, and fully-loaded had 16MB RAM.
|
| Do you need something as powerful as the ARM Cortex M7 to build
| a keyboard the way you're describing? Well, no, but you'd have
| trouble doing it with less than a 6502 or a Z80, and computer
| keyboards have existed for decades longer than those chips.
| Which were the entire CPU of microcomputers such as the Apple
| // and Commodore 128, respectively.
|
| So it would be possible now, but it would require
| rearchitecting a basic system which is working fine, for every
| operating system which could conceivably use it.
|
| Furthermore, most people would be inconvenienced by this. The
| two sides of the coin are, on the one hand, you plug in your
| mechanical keyboard into any computer and it Just Works. On the
| other hand are people who switch keyboard layouts. They
| outnumber the mech enthusiasts by what must be hundreds to one,
| switching layouts based on what one is doing is very common in
| Europe and ubiquitous in places where the language is written
| using a script which isn't derived from the Latin one.
|
| So that's the historical reason why it didn't happen, and the
| contemporary reason why it still hasn't, and probably won't.
| This actually inconveniences me, I have to jump through several
| levels of hoop to put Unicode characters on the higher planes
| of my split-key, but it is what it is.
| DavidVoid wrote:
| 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
___________________________________________________________________
(page generated 2024-04-08 23:01 UTC)