Entering a key whilst two OSL layers activated simultaneously locks the first pressed layer

[sypl]

I'm finding this problem:

Setup:

I have two OSL layers:

#define LOWER OSL(_LOWER)
#define RAISE OSL(_RAISE)

Actions

• I hold down both LOWER and RAISE (and let's say I hit LOWER slightly earlier than RAISE)
• Whilst LOWER and RAISE are still down, I hit 'a'

Result

I get the character for RAISE+a

But!

• I now hit 'q', 'm', 'k'

Further result

I get the characters for LOWER+q, LOWER+m, LOWER+k. In effect, LOWER layer, the layer key I hit first, is locked. I can only get out of it by tapping LOWER.

Consequences

It makes things buggy if I'm trying to activate something on ADJUST (LOWER + RAISE) layer.

[drashna]

Have you tried holding down the OSL keys, or tap toggle them?

[sypl]

I do hold them down, and that seems to lock one of the layers. It's a pretty easy bug to reproduce, give it a try off the default planck layout (or any with LOWER + RAISE = ADJUST).

I'm taking a look, but haven't quite figured out how this is happening yet.

[drashna]

looking at the code, I think this has to do with the way that the layers are handled.

Unfortunately, I don't think that this is an easy fix, either.

[sypl]

I found a workaround:

Don't use layer_state_set_user.

Instead, create momentary ADJUST layer:

#define LOWER OSL(_LOWER)
#define RAISE OSL(_RAISE)
#define ADJUST MO(_ADJUST)

And have the 'other' layer key (other being where RAISE would be if you first press LOWER, and vice-versa) set to new ADJUST momentary layer.

Note the bottom rows on the three layers:

[_QWERTY] = LAYOUT_planck_mit(
    ALTTAB,  KC_Q,    KC_W,    KC_E,    KC_R,    KC_T,    KC_Y,    KC_U,    KC_I,    KC_O,    KC_P,    ALTDEL,
    CMDESC,  KC_A,    KC_S,    KC_D,    KC_F,    KC_G,    KC_H,    KC_J,    KC_K,    KC_L,    KC_SCLN, CMDENT,
    LSHIFT,  KC_Z,    KC_X,    KC_C,    KC_V,    KC_B,    KC_N,    KC_M,    KC_COMM, KC_DOT,  KC_SLSH, RSHIFT,
    KC_LCTL, _______, _______, _______, LOWER,      KC_SPC,       RAISE,   _______,   _______, _______, KC_RCTL
),
[_LOWER] = LAYOUT_planck_mit(
    _______,  KC_Q,   KC_W,    KC_F,    KC_P,    KC_G,    KC_J,    KC_L,    KC_U,    KC_Y,    KC_SCLN, _______,
    _______,  KC_A,   KC_R,    KC_S,    KC_T,    KC_D,    KC_H,    KC_N,    KC_E,    KC_I,    KC_O,    _______,
    _______,  KC_Z,   KC_X,    KC_C,    KC_V,    KC_B,    KC_K,    KC_M,    KC_COMM, KC_DOT,  KC_SLSH, _______,
    _______,  _______, _______, _______, _______,       _______,    ADJUST, _______, _______, _______, _______
),
[_RAISE] = LAYOUT_planck_mit(
    _______, KC_QUOT, KC_COMM, KC_DOT,  KC_P,    KC_Y,    KC_F,    KC_G,    KC_C,    KC_R,    KC_L,    _______,
    _______, KC_A,    KC_O,    KC_E,    KC_U,    KC_I,    KC_D,    KC_H,    KC_T,    KC_N,    KC_S,    _______,
    _______, KC_SCLN, KC_Q,    KC_J,    KC_K,    KC_X,    KC_B,    KC_M,    KC_W,    KC_V,    KC_Z,    _______,
    _______, _______, _______, _______, ADJUST,    _______,    _______, _______, _______, _______, _______
),

Finally, set #define PREVENT_STUCK_MODIFIERS is set in config.h.

[sypl]

I closed this because I've found a way to work around it that seems reasonable. I'm not sure if the underlying issue needs fixing so I've closed this. Re-open if you think it does need fixing in the core.

[sypl]

Reopening as it seems like this does cause problems when activating more than one OSL/OSM key at a time: #3939 (comment)

[drashna]

Well, OSM should be fine when more than one are used at a time, because it adds to the bitmask, basically. But OSL isn't handled/tracked properly.

I don't think that what you've mentioned with the OSM is the same issue... or even an issue, and it .... may be the one shot tap toggle functionality that you're seeing.

[drashna]

Here is a big chunk of the one shot code

https://github.com/qmk/qmk_firmware/blob/master/tmk_core/common/action.c#L256-L295

https://github.com/qmk/qmk_firmware/blob/master/tmk_core/common/action.c#L470-L505

[sypl]

Yes, I think you're right about them being separate issues. I've filed another issue about OSMs getting locked: #3963

The issue with two OSLs still exists, so I'll leave this open in case anyone has ideas about solving it properly, rather than relying on my previously mentioned workaround.

[danielo515]

Your workaround seems reasonable @sypl, thanks

[jackhumbert]

I think this is a pretty reasonable workaround - I'm gonna close this for now, but if anyone has other ideas, feel free to share them here!