Releasing a layer modifier switches back to default layer regardless of how many modifier keys are held down simultaneously.

[nostdm]

Describe the Bug

(Keymap screenshots at the bottom)

I have two MO(1) keys on my keyboard layout - one under my left thumb and one under my right thumb. On Layer 1 which is the layer that the modifier switches to, I have set the corresponding key to be KC_TRNS as I have understood from the documentation that this is the correct way to have the layer modifier work correctly on both layers.

The behaviour that I would expect from the MO(layer) modifiers is akin to the standard keyboard modifiers like Ctrl, Alt, Shift, Super etc. for example:

1. I press and hold left Shift which allows me to write capital letters.
2. While still holding the left Shift I can also hold down the right Shift (i.e. holding both keys down) and still type capital letters.
3. I can let go of either of the Shift keys and still be able to write capital letters.
4. Only once I let go of both Shift keys the modifier is finally set to an off state.

However what happens with the MO(1) modifier is the following:

1. I press and hold the left MO(1) key which enables the corresponding Layer 1
2. I press and hold the right MO(1) key (i.e. holding both MO(1) keys) and layer remains at Layer 1
3. However, as soon as I release either of the MO(1) keys the layer switches back to Layer 0 even though I'm still holding one of the MO(1) keys.

It seems that releasing one of the modifier keys tells the keyboard to switch back to the default layer without taking into account the total amount of modifier keys being held down.

Could it be that I have set up the layer modifiers incorrectly or is this a bug?

System Information

• Keyboard:
  IDOBO 75 (AVR microcontroller)
  • Revision (if applicable):
    Installed from Arch repository qmk --version says unknown but package says it's 0.0.36
• Operating system: Linux 5.9.3-arch1-1 x86_64 GNU/Linux
• AVR GCC version: 8.3.0
• QMK Firmware version: 0.10.39
• Any keyboard related software installed? A couple of custom keys defined via XKB on Linux (most likely not relevant to this issue)

Additional Context

Layer 1 and Layer 2 on my current keyboard layout (including the MO(1) keys in question):

[orogenic]

I emailed ergodox-ez about this behaviour back in October 2020.

My email:

Hi, I own an Ergodox EZ original and I have a feature request for the Oryx configurator. Maybe you can help clarify the solution to my problem as well.

I have two MO(1) keys on my base layer, one for the left hand, one for the right hand. When I press both of them, and depress one of them, the layer switches back from 1 to 0. This behavior is not desirable for my use case. Similar to how if I press both shift keys and then depress one of them, the next key I type will still apply a shift modifier, I think it ought to be the same case, or at least a configurable case, for my MO keys.

The reply I received:

The behavior of MO keys comes comes down to QMK (our open-source firmware), and they behave differently than Shift keys because Shift is built-in to the USB keyboard standard, while layer keys are features specific to the firmware you're running.

In particular, what's going on with MO is that, on a "key down" event, the layer is triggered, and then the layer is deactivated on a "key up" event -- in the case of your example, on the first "key up" event. The firmware doesn't know that another MO keys is still being held down; it only knows that an MO "key up" event was sent, which means that the layer should be deactivated. If you're interested in checking out QMK, you may be able to write your own custom function with different "key down/hold/key up" behavior.

Could it be that I have set up the layer modifiers incorrectly or is this a bug?

Based on how I understood their reply, I'm gonna go with "limitation" or "unimplemented" rather than "bug", and your setup makes sense to me at least.

I decided I'd finally like to dig into QMK and figure out if what we both want is possible. Honestly I am glad to find your issue. I would have had a hard time believing I'm the only one who wants this behaviour haha. as you mention, the standard keyboard modifiers work this way, after all. I will be compiling for ergodox ez so I do not necessarily know if what I discover will be applicable to your keyboard, but I suspect if there is a solution, it should be one we can both use, based on what I understand so far about QMK.

edit: I never got around to this. Instead, I workaround it by making two copies of the layer. Pressing both layer keys and depressing one, one of the layers is still active.