(To be more precise, if you want a Q on a key, and the computer is configured as QWERTY, you just put KC_Q in your mapping, but if you know the computer is configured as french AZERTY, you can use FR_Q... which is basically a KC_A in disguise. I'm not a fan of all those #defines, but at least it's simple and compile-time)
Well, if FR_Q is a #define, I guess it must look something like :
#define FR_Q KC_A
or more likely this
#define KC_A 31
#define FR_Q 31
Actually, the first but it doesn't matter... It's probably 0x14 (20) rather than 31, too, IIRC.
Edit: 0x04, my bad... since you're referring to QWERTY A
meaning that before the compilation process starts, FR_Q and KC_A will be replaced by 31, which makes it US qwerty.
I'd argue that, for a ANSI/ISO keyboard, codes refer to a physical position, not an actual symbol... So, to me, it's layout-independant.
Granted, with USB HID, the numbering isn't a line/column numbering like it used to be, and the way they designed it, there's a QWERTY bias. You can associate UsageID with symbols (letters) if you want, but to me, the 0x14 UsageID mean AT's position 17, which isn't tied to a specific letter (since that depends on the keyboard)
That being said, it's almost philosophical, and it's not important for the user...
What I meant is, it's totally symmetric in QMK firmware:
If you've installed a QWERTY keyboard, use KC_Q to reference the letter Q, it'll send a 0x14, and you'll get a Q
If you've installed an AZERTY keyboard, use FR_Q to reference the letter Q, it'll send a 0x04, and you'll get a Q
You just have to hardcode in the firmware which UsageID is linked to which symbol. QMK has basically all mappings (QWERTY, AZERTY, QWERTZ...) defined...
When you say "switch language" at runtime (on the keyboard side), it means your language on the computer side will need to be US English (ANSI or ISO or Whatever) as it is used as reference for your layers to work as you programmed them.
Well, no, precisely...
What I mean is that if I associate a physical key to KEY_Q in a layer, when I send the UsageID, I use a second translation table. So I can choose, at runtime, whether I send a 0x14 or a 0x04.
For example, when the OS is launched, I have an AZERTY layout installed. When I press Q, a Q appear on screen. Now, for some reason (BIOS lacking layout support, old DOS game, etc.), a software assume a QWERTY layout. If I press Q, I would normally get A.
In this case, I just press the QWERTY/AZERTY switch on the keyboard, and I get Q in the DOS game without any change in the computer side.
(*): Unless there is a scancode or an instruction that the os is hooked to to perform a software switch of the layout somehow... maybe as part of a driver... dunno, i'm way out of my league here. or maybe a unicode thing, which I have not dug yet.
There is, but it's OS dependant, and I don't want this.
It's actually like the keyboard disguising itself.
The OS think you have a QWERTY keyboard? My firmware will act as a QWERTY keyboard.
Now it assumes you have an AZERTY one? A single switch, and the firmware act as an AZERTY one.
In other words:
* first table, in firmware:
physical position -> unicode identifier
* second table, in firmware
unicode indentifier -> UsageID code
* third table, in OS :
UsageID code -> actual character typed
Thing is, you don't always has control on the third table, since it's the layout installed on the OS (or hardcoded into the application)
Most firmware merge the first two translations into a single one: physical position -> UsageID code.
Problem is, you need to know the third table (thus the hardware configuration) when you compile the firmware...
By handling a double translation mechanism, I can adapt to different layout installed in the OS.
I probably should do a video, it would be simpler
Beside the obvious "****, it's configured as QWERTY" issue, I use a very different layout on my computers (more symbols, and characters in unusual places). I obviously want to be able my keyboard with my specific layout installed (partly because there's plently of characters in it that are neither in AZERTY nor in QWERTY).
But if I plug my keyboard into someone else computer (which will be either AZERTY or QWERTY), I want it to work normally, without touching anything in the computer configuration.