Click to view our Accessibility Statement or contact us with accessibility-related questions
Showing 1 of 481 conversations about:
Sejsel
1
Sep 3, 2016
bookmark_border
How does the programming work with OS' keyboard layouts? Does it completely override them, or can the OS keyboard layout mess it up? (Mostly interested in how it works with Linux)
Sep 3, 2016
rabs
6
Sep 4, 2016
bookmark_border
SejselThe OS shouldn't mess anything up - the keyboard just sends a keycode for each key and the OS will interpret it. It may or may not be more difficult on each OS depending on how the firmware runs on (guide here: https://thevankeyboards.com/pages/programming-guide).
Sep 4, 2016
Sejsel
1
Sep 4, 2016
bookmark_border
rabsAs far as I know, the firmware runs on the keyboard's microcontroller, not the OS. I hope it will work the same with multiple computers and on both Linux and Windows.
Sep 4, 2016
Sakis
114
Sep 4, 2016
bookmark_border
SejselLinux user here (only to clear any doubt you might have - behavior should be the same across all operating systems). So, when keyboard is programmed as a Dvorak/Colemak it takes all the weightlifting of translating presses to their respective qwerty keycodes expected by operating system. Therefore, if you got a keyboard programmed to be Dvorak, you want keyboard layout on operating system to be qwerty. If both keyboard is Dvorak and operating system is on Dvorak layout, then it ain't Dvorak anymore, nor qwerty.
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".
Sep 4, 2016
Sejsel
1
Sep 4, 2016
bookmark_border
SakisThank you for such a detailed answer. That is how I thought it most likely works. I will just have to make sure that all the devices are set to the same layout. Which is sadly quite impossible as the differences between Linux and Windows layouts are quite big (and the Windows ones are way worse, imho).
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.
Sep 4, 2016
Sakis
114
Sep 4, 2016
bookmark_border
SejselWell. If you feel like getting your hands dirty, you can program your keyboard to have several different layers, appropriate for each operating system.
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.
Sep 4, 2016
captain
240
Sep 4, 2016
bookmark_border
SakisWhen you press the "A" key on an ASCII standard keyboard, the keyboard controller sends electronic signals representing "ASCII key code 65" to the computer. If you reprogram the keyboard controller to send a different key code when that *standard A key* (let's assume you're converting to a french keyboard, where Q is in the place where A resides on an ASCII keyboard ;-) is pressed, then the keyboard will send the new code (ASCII key code 81 for "Q") to the computer. If you have your computer programmed to "translate" key code 65 to something else, then obviously nothing will happen when the keyboard sends key code 81. I hope that makes sense. If you're curious to see what keycodes are being sent when you press your keyboard keys, check out this site:
https://www.w3.org/2002/09/tests/keys.html
Sep 4, 2016
Sakis
114
Sep 4, 2016
bookmark_border
captainI am not sure what this link illustrates - looks like a browser test to me.
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.
Sep 4, 2016
evangs
1492
Sep 4, 2016
bookmark_border
SejselIt will
Sep 4, 2016
Sejsel
1
Sep 4, 2016
bookmark_border
SakisThank you for the layer-per-os idea, I didn't think of that. I might end up doing that, it's about the best way to get it to work how I want.
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.
Sep 4, 2016
Eagleheardt
34
Sep 6, 2016
bookmark_border
evangshey man, I messed up and should have signed up for a lightcycle set of caps. Is there any way I can squeeze in and get a set? :(
Sep 6, 2016
evangs
1492
Sep 6, 2016
bookmark_border
EagleheardtI will have extra sets available on https://thevankeyboards.com
Sep 6, 2016
View Full Discussion
Related Products