3 ms·

It's ancillary to this post, but I don't understand this obsession with "programmable" keyboards, at least for plain remapping of keys. There's entirely no poi

It's ancillary to this post, but I don't understand this obsession with "programmable" keyboards, at least for plain remapping of keys. There's entirely no point in doing it; the keymap / layout (not application key bindings, before that) is what gives keys meaning to begin with. Why would you care about what keycode a keyboard sends for some key? The only thing that matters is NKRO, if you want to remap modifiers; on non-NKRO keyboards the modifier keys are different in that they don't clash with other keys. If the keyboard has some macro function, okay, I can see that being useful, in rare circumstances (in most cases you could also just do that in software.) Meanwhile, the only way to get a keyboard that has 2 physical keys in the space where the wide caps lock key is on a "normal" keyboard is to build it myself. That key is the one completely useless key in the "core" of a regular layout, and I'd really like to be able to put 2 custom functions there (rather than just 1).

uncircle 1y ago
The keymap functionality in your OS is a hack because most keyboards are not programmable. I use a split keyboard in a Colemak layout, and it's programmed to send the correct keys despite them being in "different" places compared to a normal keyboard, so I don't have to mess with keymap switching on the operating system. I just plug it in and it works. Also what you deem obsession is called ergonomics. Since a programmer uses a keyboard 100% of the time they spend in front of a computer, optimising for ergonomics is a great time investment. My symbol layer is so much more sane and comfortable than having to use Shift-number like an ape (no offence). In the home row under my strongest fingers, for example, I have "():_= which are the most common symbols in popular programming languages. My two thumbs are not wasted to press an humongous space bar, but have access to modifiers such as Shift and Ctrl instead of having to use my pinkies. The secret to not losing muscle memory when you have to go back programming like an ape on a regular keyboard, is to choose a very different physical layout (like an ortholinear split keyboard) for your programmable keyboard. Then you're just learning another "instrument" which is spatially laid out differently than what you are used to, retaining your memory of QWERTY on a regular keyboard.
- eqvinox 1y ago
  That's a matter of perspective. Sure, the keyboard could know the labels printed on it and send the proper key, and you could see it as "change my labels, change my keyboard's understanding of the labels and send the right thing". Or, you could see it as "the keyboard is an input device with about a hundred possible actors, that have something printed on them to help the user distinguish". An input device's function —even if it is a keyboard— is being an input device, not necessarily inputting letters or keys. If I want to map the key labeled "U" to bring up the second last terminal window, that's valid. Not being able to input "U" now is my problem to solve. And a programmable keyboard, as programmable as it might be, can never cover the undefined set of things users around the world would want to make some keys do. So you'd have to split it in two remapping operations. But why? It's added complexity and confusion. In your specific case, my position (which, yes, because it's not how things work in USB/BT/…, is somewhat meaningless) is that there should be a function where the keyboard reports both the labels on its keys as well as the physical layout. (And then keypresses relative/in reference to that.) And the thing that kinda drives my position home is an annoyance a lot of German (QWERTZ) and French (AZERTY) people know: Game inputs quite commonly use WASD layouts, and those get warbled quite a bit. As they would (even worse) on your reprogrammed Colemak layout. P.S.: your "ergonomics" and "use a very different layout" points seem to have misunderstood my position/argument. I'm saying remapping keys / different layouts should be a general OS/software function, not something the keyboard does in its microcontroller. I'm entirely on board with "fancy" layouts.
  - uncircle 1y ago
    > there should be a function where the keyboard reports both the labels on its keys as well as the physical layout You can move the keycaps around, though you'll find they don't all have the same height. Or wait until someone releases a keyboard with a small e-ink display in each keycap that doesn't cost an arm and a leg. QWERTY is not a problem. I have a dedicated layer just for games, which is actually a QWERTY/Colemak hybrid. The left side is QWERTY, as most game keys are bound near WASD, while the right side matches closely my Colemak key maps, so whenever I have to write text in QWERTY mode, I just have to mentally map from QWERTY the left-side. In practice, this is not a problem. Non-rebindable games are just small indie ones I find on itch.io that only use WASD. The rest that have in-game text chat I rebind, and Colemak anyway is very close to QWERTY not to make that effort too onerous. 99% of games are just WASD + TEF. Re: QWERTZ and AZERTY: those are abominations and shouldn't exist. I use QWERTY everywhere + a dedicated Compose key for diacritics. This is my layout: https://imgur.com/a/TpJMTBH https://imgur.com/a/TpJMTBH
tmtvl 1y ago
Some programs are poorly behaved (Wayfire used to be this way) and directly read keycodes rather than keysyms.
- eqvinox 1y ago
  I mean, yeah, sure, but how is it a sensible fix for that to change the hard-/firmware rather than to fix those programs?

uncircle 1y ago

The keymap functionality in your OS is a hack because most keyboards are not programmable. I use a split keyboard in a Colemak layout, and it's programmed to send the correct keys despite them being in "different" places compared to a normal keyboard, so I don't have to mess with keymap switching on the operating system. I just plug it in and it works. Also what you deem obsession is called ergonomics. Since a programmer uses a keyboard 100% of the time they spend in front of a computer, optimising for ergonomics is a great time investment. My symbol layer is so much more sane and comfortable than having to use Shift-number like an ape (no offence). In the home row under my strongest fingers, for example, I have "():_= which are the most common symbols in popular programming languages. My two thumbs are not wasted to press an humongous space bar, but have access to modifiers such as Shift and Ctrl instead of having to use my pinkies. The secret to not losing muscle memory when you have to go back programming like an ape on a regular keyboard, is to choose a very different physical layout (like an ortholinear split keyboard) for your programmable keyboard. Then you're just learning another "instrument" which is spatially laid out differently than what you are used to, retaining your memory of QWERTY on a regular keyboard.

eqvinox 1y ago
That's a matter of perspective. Sure, the keyboard could know the labels printed on it and send the proper key, and you could see it as "change my labels, change my keyboard's understanding of the labels and send the right thing". Or, you could see it as "the keyboard is an input device with about a hundred possible actors, that have something printed on them to help the user distinguish". An input device's function —even if it is a keyboard— is being an input device, not necessarily inputting letters or keys. If I want to map the key labeled "U" to bring up the second last terminal window, that's valid. Not being able to input "U" now is my problem to solve. And a programmable keyboard, as programmable as it might be, can never cover the undefined set of things users around the world would want to make some keys do. So you'd have to split it in two remapping operations. But why? It's added complexity and confusion. In your specific case, my position (which, yes, because it's not how things work in USB/BT/…, is somewhat meaningless) is that there should be a function where the keyboard reports both the labels on its keys as well as the physical layout. (And then keypresses relative/in reference to that.) And the thing that kinda drives my position home is an annoyance a lot of German (QWERTZ) and French (AZERTY) people know: Game inputs quite commonly use WASD layouts, and those get warbled quite a bit. As they would (even worse) on your reprogrammed Colemak layout. P.S.: your "ergonomics" and "use a very different layout" points seem to have misunderstood my position/argument. I'm saying remapping keys / different layouts should be a general OS/software function, not something the keyboard does in its microcontroller. I'm entirely on board with "fancy" layouts.
- uncircle 1y ago
  > there should be a function where the keyboard reports both the labels on its keys as well as the physical layout You can move the keycaps around, though you'll find they don't all have the same height. Or wait until someone releases a keyboard with a small e-ink display in each keycap that doesn't cost an arm and a leg. QWERTY is not a problem. I have a dedicated layer just for games, which is actually a QWERTY/Colemak hybrid. The left side is QWERTY, as most game keys are bound near WASD, while the right side matches closely my Colemak key maps, so whenever I have to write text in QWERTY mode, I just have to mentally map from QWERTY the left-side. In practice, this is not a problem. Non-rebindable games are just small indie ones I find on itch.io that only use WASD. The rest that have in-game text chat I rebind, and Colemak anyway is very close to QWERTY not to make that effort too onerous. 99% of games are just WASD + TEF. Re: QWERTZ and AZERTY: those are abominations and shouldn't exist. I use QWERTY everywhere + a dedicated Compose key for diacritics. This is my layout: https://imgur.com/a/TpJMTBH https://imgur.com/a/TpJMTBH

tmtvl 1y ago

Some programs are poorly behaved (Wayfire used to be this way) and directly read keycodes rather than keysyms.

eqvinox 1y ago
I mean, yeah, sure, but how is it a sensible fix for that to change the hard-/firmware rather than to fix those programs?