<<Chrysalis layout vs. OS layout neutralizing themselves>>


Just have received my Atreus. First thing I did after shipment delivery: tweak it to an ISO-FR layout (by physically switching keys) and plug it to try it. So far so good… Strangely.
Meaning, pressing what is supposed to be a “Q” in the default factory layout generate an “A” input at the OS level. But so far so good, I just unboxed the thing and I wanted an A. It’s great. Anyway.

Cue in the following day, now I had time to install Chrysalis. I updated the FW, then I tweaked the onboard layout of Chrysalis. And that’s where the fun begins.

Let’s review all the variables here:

    • HW : Atreus keys switched (for instance I’ve interverted A/Q, W/Z and so on),
    • SW : Atreus onboard layout updated (again I’ve interverted A/Q, W/Z and so on),
    • SW : My current OS, W10 is set to an “FR-fr” layout
  • All that together, and pressing my “A” physical key, generate a “Z” input…
  • If I switch my OS locals to an EN-en layout, then pressing my “A” physical key, generate a “A” input.
  • If I undo my layout update in Chrysalis, pressing my “A” physical key, generate a “A” input.

As I see it, it feels rightly unlogic. If everything is set to “ISO-FR”, I obtain an ISO-UK. If one of the 2 possible SW variables is set differently than the other, then I get the expected result.

To add a little more fun, I also interverted “SPACE” and “BACKSPACE” letters on Chrysalis (it feel more natural to me this way). And this works smoothly, the behavior is just as expected whatever the OS setting.

Why does both Chrysalis and OS layouts setups neutralize themselves (and only for letters)?

Keyboards communicate with the OS through key-codes, not actual symbols.

The keyboard only sends a keycode - what to do with the keycode is completely up to the operating system. So, a non-programmable AZERTY keyboard (which I assume as you said Q produces A) will send the same code when you hit the physical A key as a US layout keyboard would send when you hit its physical Q key - making it an A instead of a Q is due to your OS level layout.

If you now change the layout on your programmable keyboard to send the code for the (US - layout) A key when hitting the physical position of Q - your OS layout will produce whichever symbol it associates with that code.

Basically, if you use a non-US layout on your OS, you might want to stay with the basic US key layout on the keyboard (in firmware that is, changing the keycaps of course has no impact here). The other way would be to program the keyboard to reflect your language layout and use an appropriate OS layout like US-International (But it is more complicated to produce special symbols then).

The effect is not noticeable on non-alphanumeric keys like Ctrl, Space or even plain numbers, as they are in the same position all common layouts - so the keycodes are interpreted to the same symbol/effect.

1 Like

If I get your answer right, what is then the interest and purpose of being able to design our own onboard layouts?

Why have I been able to switch SPACE and BACKSPACE successfully, at the firmware level, and not for some letters keys?

Because Space and Backspace are at the same place in QWERTY and AZERTY :slight_smile:

Basically, the keyboard reports just : key_line1_column1_pressed and the OS says : ok, we got a q (in QUERTY) or a a (in AZERTY), or a b (in BÉPO), …

One of the purpose is to have the keyboard report a different keycode than the one pressed. For example, you can have more than one layout on your keyboard and switch depending of the context of use. My computers are in US International, so when I press the top left key, I my OS get :

  • key_line1_column1_pressed (q) on Layer 0 (QWERTY layer I use for programming)
  • key_line3_column5_pressed (b) on Layer 4 (BÉPO layer, when typing french text)
  • key_line2_column1_pressed (a) on Layer 7 (AZERTY layer my mother can use)

If you only need one layout, you can have the reverse behavior, and having the same layout on computers using different configuration so you can write on every place you plug your keyboard :

  • Layer 0 : bépo on a QWERTY OS (My computers)
  • Layer 4 : bépo on a AZERTY OS (so much french pcs)
  • Layer 7 : bépo on a BÉPO OS (some of my coworkers)

The advanced part of programming your keyboard, is to have the key you need where you want, and behave like you want (the j key can write j when you tap it and be a Shift when you hold it and press an other key, or you can have a key that write Cordialement because you use this a lot, or a Leader key followed by actions, or a layer with all the Esc-Meta-Alt-Ctrl-Shift key you need for strange editors, or …

Happy hacking :slight_smile:


1 Like

I also just received my Atreus.
As fneuf, i’d like to configure it for using in bépo
Romain, you convinced me to put hands in it by programming.
The point is that i don’t know where to start even for adding iso french to the keyboard (to get é,à,etc on direct access).
Could you please tell me where to start or find a tuto?


I got my atreus recently and start to make a bépo layout.
Here is my layout AtreusBepo.ino (15.9 KB) if this can help.

I’m not sastify with my code but it does the job. I’ll probably improve it with define to avoid some macro.

For documentation, I use


Great initiative rloic,
Are you hosting the code somewhere we could collaborate?

No, the code is not hosted. I’m not familiar with this.
You can use and host it as you want. I would be happy to collaborate.

Thanks for your inputs and sorry for the lateness, it was clearly a busy October.

Have to admit I steel feel like “a chicken just having found a knife” as per the idiom we say in french. I’m not sure I understand this Atreus tool yet.

If I keep it basic: how can I, very simply, decide of the use of each key, once and for all?
Basically I mean by that my Chrysalis maps becomes the lead, the “truth”. Wherever I plug it to, whatever the OS, the default OS keyboard setting, what I’d have decided as key value for “key_line1_column1_pressed” will always be reported the same, and be what I chose. And so on for every key and layers. How do I achieve that?

The short answer is you can’t. The interpretation of keycodes is a software task, not a hardware one. All that you can do in the embedded firmware is make the keys generate keycodes that you hope your software will interpret a certain way. If you know in advance what your software expects (i.e. what language your computer is configured to use) then this task is easy. But you can’t do it in a way that works predictably on an unknown, arbitrary computer.