3 ms·

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 manag

by 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]
mrob 3y ago
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 3y ago
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 3y ago
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.

by rrgok 3y ago

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]

mrob 3y ago

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 3y ago

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 3y ago

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.