qmk / qmk_firmware

Open-source keyboard firmware for Atmel AVR and Arm USB families
https://qmk.fm
GNU General Public License v2.0
17.54k stars 37.82k forks source link

[Bug] Multiple OSM modifiers don't work on a layer activated with layer-tap and HOLD_ON_OTHER_KEY_PRESS #20269

Open GlassBricks opened 1 year ago

GlassBricks commented 1 year ago

Describe the Bug

Summary after some edits:

When HOLD_ON_OTHER_KEY_PRESS is on, pressing multiple OSM keys together (on another layer) loses the OSM behavior. This happens with the layer activated either through MO or LT.

Previous (outdated) description:

I have OSM modifiers on a "nav" layer. I recently changed the key to activate the nav layer from MO (momentary) to a LT (layer tap). (EDIT) If I press multiple OSM keys, the modifiers are no longer OSM. (EDIT 2) This issue seems to only occur with HOLD_ON_OTHER_KEY_PRESS.~~

Using Elite-Pi controllers on a split keyboard.

Keyboard Used

splitkb kyria rev3

Link to product page (if applicable)

No response

Operating System

No response

qmk doctor Output

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.1
Ψ QMK home: /home/(usr)/qmk_firmware
Ψ Detected Linux (Pop!_OS 22.04 LTS).
Ψ Git branch: master
Ψ Repo version: 0.20.0
⚠ Git has unstashed/uncommitted changes.
Ψ - Latest master: 2023-02-28 11:22:29 +1100 (bacec14073) -- Merge remote-tracking branch 'upstream/develop'
Ψ - Latest upstream/master: 2023-03-27 09:56:09 +1100 (3ee17cd5d3) -- [chore] keyboards/tzarc: Alignment with clang-format. (#20265)
Ψ - Latest upstream/develop: None
Ψ - Common ancestor with upstream/master: 2023-02-28 11:22:29 +1100 (bacec14073) -- Merge remote-tracking branch 'upstream/develop'
Ψ - Common ancestor with upstream/develop: None
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 10.3.1
Ψ Found avr-gcc version 5.4.0
Ψ Found avrdude version 6.3-20171130
Ψ Found dfu-programmer version 0.6.1
Ψ Found dfu-util version 0.9
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2023-01-03 19:29:26 +0000 --  (0062927e3)
Ψ - lib/chibios-contrib: 2023-01-11 16:42:27 +0100 --  (a224be15)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/pico-sdk: 2023-02-12 20:19:37 +0100 --  (a3398d8)
Ψ - lib/lvgl: 2022-04-11 04:44:53 -0600 --  (e19410f8)
Ψ QMK is ready to go, but minor problems were found

Is AutoHotKey / Karabiner installed

Other keyboard-related software installed

No response

Additional Context

No response

sigprof commented 1 year ago

Strange; this should have been fixed by #17282, which is present in 0.20.0. (Before that change the behavior of OSM() on a layer behind LT() was broken, unless you first held LT() until the end of its tapping term, and then released it after releasing OSM().)

GlassBricks commented 1 year ago

After some more investigation (setting timeouts to be super long), I found this issue only occurs when multiple OSM keys are pressed (e.g. OSM Ctrl + Shift); Pressing multiple OSM keys works with MO() but not LT()

GlassBricks commented 1 year ago

... and with HOLD_ON_OTHER_KEY_PRESS

GlassBricks commented 1 year ago

Even more investigation later, it's only HOLD_ON_OTHER_KEY_PRESS that causes the issue with multiple OSM keys. This doesn't have to do with MO vs LT; it just happens that I only turned on HOLD_ON_OTHER_KEY_PRESS after LT.

Side note: this issue is getting modified a lot. Should I close this issue and open another one?

sigprof commented 1 year ago

Can you describe the exact sequence of key presses and releases that triggers the problem? I can't reproduce it here with LT(1, KC_CAPS) and OSM(MOD_RGUI), OSM(MOD_RCTL) on that layer; however, I'm also using the code from the develop branch (as of yesterday), so maybe there is some difference due to that.

Ciebiada commented 2 weeks ago

I have the same issue. My usecase is that I have my sticky home row mods on a momentary layer. They are sticky, so I can press the layer key, two modifiers, release everything and then press a key from my base layer resulting in e.g. cmd + ctrl + q.

HOLD_ON_OTHER_KEY_PRESS breaks this

Ciebiada commented 2 weeks ago

My current workaround is to use HOLD_ON_OTHER_KEY_PRESS_PER_KEY