Support for Alternative Layouts
This is a summary of how alternative layouts have been supported by kits such as Colevrak and Homing. It is not a discussion of alt layout performance and development, but if that interests you I highly recommend starting with Pascal Getreuer’s A guide to alt keyboard layouts (why, how, which one?). It’s a concise and comprehensive overview with links to some great sites that go deeper. He also has a separate Links about keyboards page. The Keyboard layouts doc he recommends explains layout goals and metrics in detail, summarizing the alt layouts discussed here as well as more than one hundred others. Sculpted-profile The majority of custom keycap sets are sculpted-profile (Cherry, SA, MT3, KAT, etc. - more on profiles generally here) so let’s start there. Because each row has a unique keycap shape, alt layouts require a unique keycap for each legend that moves off its QWERTY row. At first there were two The Dvorak layout was patented in 1936 by August Dvorak & William L....
Apr 23, 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.