How do you do per-key RGB lighting on a Shift V2?
I saw the online configurator that lets you do this on the Shift V1, where it spits out a compiled firmware file to flash. The V2 doesn't seem to have this function in the Windows configurator, though. I can't imagine the answer here is "you're going to have to manually write the hex for every key in QMK, compile it, and flash that".
Apr 18, 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.