What is SpaceFN and why you should give it a try
The SpaceFN concept - setting up your space key as a layer switch when held - is probably one of the most useful tweaks in the keyboard hobby. Let me explain how it works. My SpaceFN article on kbd.news made some rounds recently - quite surprisingly given the age of this concept. This piece you're reading is a condensed version of the full post. If you're left with unanswered questions, you'll most likely find the info you're looking for in the original write-up. On my imaginary top list of the most useful keyboard features, tweaks and hacks, SpaceFN would deserve a podium finish for sure. But what makes it so special? In short: SpaceFN is easy to implement, easy to learn, costs nothing, can be used with any keyboard, and can improve your productivity instantly. I will list its benefits below, but can state right at this point that the SpaceFN concept, setting up your space key as a layer switch when held, is clearly one of the most useful tweaks in the keyboard hobby....
Apr 30, 2024
To better answer your original question, a keyboard programmed with a custom layout, eliminates the need for any configuration across different computers and operating systems. For this to work, all of them need to be on qwerty layout.
All examples below use exact same physical button on a keyboard. Examples #1 and #2 work fine. Example #3 demonstrates an undesired effect.
Example #1: Dvorak programmed keyboard, OS layout set to qwerty You press "O", which sits where "S" on a qwerty keyboard is. Keyboard reports key "O" was pressed. Operating system displays "O".
Example #2: qwerty programmed keyboard, OS layout set to Dvorak You press "S" on a qwerty keyboard. Keyboard reports key "S" was pressed. Operating system translates it to "O". Operating system displays "O".
Example #3: Dvorak programmed keyboard, OS layout set to Dvorak You press "O", which sits where "S" on a qwerty keyboard is. Keyboard reports key "O" was pressed. Operating system considers "O" as coming from a qwerty keyboard and translates it to "R". Operating system displays "R".
It would be nice if the keyboard was not limited to the USB keycode standard and you could send Unicode or something like that. Sadly that would require writing a custom driver and I really don't want to do that. At least not for Windows.
I hope that the layout I have thought of will be implementable.
See here; https://github.com/jackhumbert/qmk_firmware/blob/master/keyboards/preonic/keymaps/default/keymap.c Code modifies default layer for supporting qwerty, Colemak, Dvorak. You may use a similar flow for having layers appropriate for your target system, configurable during "firmware runtime".
Moreover, both TMK (https://github.com/tmk/tmk_keyboard) and QMK (https://github.com/jackhumbert/qmk_firmware) firmwares allow using Macros, triggered by a single keystroke, for sequencing a specific sequence of keys to operating system. You can create macros that send appropriate sequences for entering a unicode character. However, this requires some more work on your behalf as not all desktop environments work the same way on this aspect. For example, on GNOME, you need to press Ctrl+Shift+U, then type hex code of unicode glyph and then press space once.
https://www.w3.org/2002/09/tests/keys.html
It surely is not what information departs from keyboard. At least when it comes to USB HID keyboards, no ASCII is transmitted. Instead a UsageID is assigned to each key (also applies to keys not having an ASCII representation, like "PrintScreen" and "Volume Up") and this is what is transmitted - and only this - for up to 6 keys simultaneously pressed, along with state each one of the modifiers currently has.
It is then up to the operating system/userland libraries to beautify and enrich input event - including association with any apparent ASCII code (by also taking state of Shift/CapsLock into consideration).
I also think (I am not sure it is there where I've read it - EDIT: had indeed been there, see reference below) even HID documentation suggests to manufacturers not to do any "smart" things for covering alternative layouts, and keep sending "Q", when user presses "A" on an azerty keyboard, and let operating system handle layout translations. [One advantage of doing so is properly written games being able to use intended WASD cluster, even on azerty keyboards. If firmware is acting smart, then player needs to modify key bindings].
Therefore, when we program a keyboard to send Dvorak/Colemak or whatever else, we actually break through HID guidelines, and based upon the unreliable assumption that host applies "qwerty layout transformation", transmit to host the equivalent qwerty UsageID, derived by another key, located somewhere else on the actual keyboard.
EDIT: See note on page #53 here; http://www.usb.org/developers/hidpage/Hut1_12v2.pdf - ASCII is certainly a responsibility of operating system. Layout transformation "better" be left to operating system. Table illustrating Usage ID of each key follows.
I know about Ctrl+Shift+U, but that does not work on Windows. Also, some keys are on different places on Windows/Linux, for example ^ and ` which are a pain to readjust to (I am not using a US layout). Also, the keymap I use on Linux even has characters like ←↓→↑/ on Level3 and Level4, Windows layouts are not even close to that.