Layering and modifier keys

[aidalgol]

I've been using an ErgoDox for a while, which had more keys than I needed, so I only used layering for a numpad.  But now I've started using an Iris, which has fewer keys, so I have to use layering.  I've settled on a custom layout with the QMK firmware that I'm mostly happy with, but I've had a problem with modifiers on layers, because I would

• be holding a modifier on layer 1
• switch back to the default layer while still holding down the modifier
• release the modifier

so the keyup event was not for the modifier, but for the key on the default layer, thus the modifier is "stuck" (until I tap it again).

So my workaround is to just avoid using modifiers on any layer other than the default, but I would like it if I could actually fix this problem.  Is this possible with the QMK firmware?

[algernon]

So my workaround is to just avoid using modifiers on any layer other than the default, but I would like it if I could actually fix this problem.  Is this possible with the QMK firmware?

It's definitely fixable, but doing so is tricky, and needs a change to how layers work. A slight change, but still one. The way around this problem is to remember which layer a key was pressed on, and when releasing, release as THAT key. This solves all kinds of problems, like layer keys having to be transparent on the target layer. In Kaleidoscope, we implemented this by having an in-memory cache of the currently active keymap. Whenever a key is pressed, we look it up from the layers, considering the currently active ones, and push it onto this in-memory keymap. Then, whenever we need the key, we look it up from there. So a release will use the same keycode as the press did, no matter how many layers you changed in between.

This is pretty simple, and only uses a single layer worth of RAM, but makes a lot of things much more predictable and intuitive.

As far as I remember, you can't *easily* do it with QMK, but you can always open a feature request there, and perhaps they'll like the idea enough to implement it.

(Or you can port Kaleidoscope to the IRIS, and not have this problem. But porting is not for the faint of heart, though should be reasonably simple as Iris uses an Atmega32U4...)

[ErgoMacros]

Thank you Algeron, I'm sure you know 10x, 100x, or more than I do, and fully respect your response.

Some others have had the same or similar problems and found solutions that may not be as elegant
or all encompassing as yours, but in case it helps aidalgol I suggest:
    do a web search for qmk stuck modifiers
    including: Still getting stuck modifiers (https://github.com/qmk/qmk_firmware/issues/1593)

Just in case that works for him.

I'm hoping Kaleidoscope comes to ErgoDox too, because I have one, and don't have a Model 01 (yet)

Peace.

[algernon]

Some others have had the same or similar problems and found solutions that may not be as elegant
or all encompassing as yours, but in case it helps aidalgol I suggest:
    do a web search for qmk stuck modifiers
    including: Still getting stuck modifiers (https://github.com/qmk/qmk_firmware/issues/1593)

Ah, right. That should work too, indeed. Thanks!

Judging by the docs, it appears to be very similar to what we did in Kaleidoscope. In spirit, it's the same.

I'm hoping Kaleidoscope comes to ErgoDox too, because I have one, and don't have a Model 01 (yet)

It has come  (Despite the name, works on the OG ErgoDox, the EZ, and anything else that is wired like them, such as some Dactyls)

My ErgoDox sketch shows how to use Kaleidoscope on an EZ.

[ErgoMacros]

Ah, a happy day indeed!
Thank you for all your work on this, Kaleidoscope, and the deep thinking on
keyboard usage. Amazing contributions to the community and the art.

[Findecanor]

The way around this problem is to remember which layer a key was pressed on, and when releasing, release as THAT key.

Huh?

The way I do it in my own firmware is to have an array with a byte for each key. A key's element is 0 if not pressed, or the key code of the pressed key. Then you don't have to care about where the key code comes from, i.e. it is only the active layer at the time the key was pressed that matters.
I thought this was how TMK worked, and I had expected QMK (a fork of TMK) to work the same way.

Edit: I checked the source. Apparently TMK just uses bitfields, not an array.