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 6 days ago | parent [-]

> 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

	▲	eqvinox 6 days ago \| parent [-]
		I can't help but notice nothing you're arguing is in relation to which part of the system should be doing the mapping from abstract keys to actual letters. As such I don't see anything to engage with… (It's also a bit strange that you argue your freedom of choice to use Colemak and then immediately proceed to call two other layouts "abominations and shouldn't exist". And this is where I'm cutting my participation in this course, because even though I absolutely agree they exist, I'm not interested in discussing objective advantages of keyboard layouts over each other. If you're arguing ergonomics, you need to accept that for a lot of people the thing they're used to is the most ergonomic because the cost of adjustment far outstrips the benefits.)