Issue with Home Row Mods on ZMK (Previously Working on QMK)

[cursive berry]

Hi everyone,
I'm having trouble getting my keymap to work correctly after switching from QMK to ZMK.

I’m trying to use home row mods on my 36-key split keyboard.
You can find my keymap here

✅ What works:
Single-modifier combos work fine.
Example: Cmd + V for paste.

❌ What doesn’t work:
Multi-modifier combos don’t behave correctly.
Example: Shift + Cmd + V doesn't register as expected.

macOS App Switch (reverse navigation) fails.
Steps:

1. Press Cmd + Tab → Enters app switcher.
2. Hold Cmd → Keeps app switcher open.
3. Press Shift → Expected: Navigate backwards in app list.
   Actual: App switcher exits immediately.

It seems like holding a home row mod (e.g., Cmd) and then pressing a second mod (e.g., Shift) breaks the intended behavior.

Any help or guidance on how to fix this in ZMK would be greatly appreciated!

[rich sphinx]

Good news first of all, its not an issue with ZMK but with your config. My HMRs work like you describe on MacOS. I will take a look at your config, gimme a few minutes

Have you tried it with both rshift and lshift?

[cursive berry]

I tried different combinations and implementations (you can see in my keymap diffent implementation of hm in my behaviors block)

yes, forgot to mention in my main message, if I use for example:

Press Left Cmd + Tab → Enters app switcher.,
Hold Left Cmd → Keeps app switcher open.,
Press Right Shift while keeping Left Cmd → it works as expected

[rich sphinx]

Hm, can you rule out something being wrong with your left shift mechanically? I once had a key that sometimes worked because it was bent in just the right way to sometimes make contact with the hotswap socket.

Also, is it the same if you move the shifts to a different key?

Have you tried using default settings instead of your own config for testing?

[cursive berry]

I'll try moving the shift to a different key, can you please share your keymap so I can take inspiration and see why yours is working and mine not?

Btw, I used for over a year the same PCB for a wired version of my keyboard, which I now converted to wireless, and the switch contacts always worked fine

I'll try to have a look at the MCU, which is the only point of failure I can think of after the conversation from wired to wireless

But since the issue is on both side is less likely I guess 🙈

Unfortunately I don't have any default settings

Should hm be implemented differently for shift? 🤔

[rich sphinx]

I use the same for all my homerow mods https://github.com/grasegger/anna_arch/blob/trunk/boards/shields/anna_arch/anna_arch.keymap#L252 and only configured the prior-idle and flavor https://github.com/grasegger/anna_arch/blob/trunk/boards/shields/anna_arch/anna_arch.keymap#L50

Also I don't think its your mcu when its working on other keys, and connections, esp hotswap, can come loose over time

[cursive berry]

Wow this comes as a surprise!

thanks to your suggestion I tried to move the shift key to another position on the same half and now it works as expected 🙈

What can cause the problem with that specific key 🤔
(Same issue if I try to do the same with the other half)

Can it be hardware? or only software maybe coming from other files?

I believe more software as it's happening also on the other half, but 🤷‍♂️

[rich sphinx]

Did you use the same binding for shift on the other keys? (HMS you call it I think?)

It could be something about the board and the key position but I can’t image what.

[cursive berry]

Yes, I just c/p &hms LSHFT A, on the Z key and also on the Q key and both work as expected

Could it be something related to the overly files or in the dtsi included in it?

[rich sphinx]

try commenting out your caps lock combo please

that uses exactly the keys that are not behaving

(also, look into caps word, a nice alternative to caps lock if you use it often)

[halcyon moat]

If you have a combo involving multiple HRMs, then combining mods requires extra steps to make them work as expected. Without extra steps, combining them will trigger the combo

[cursive berry]

thank you both for the inputs, I tried to remove all the combos that I have around HM keys, but still not working

here is the temp branch I'm using for test

[rich sphinx]

hm, it was worth a shot, I see nothing else that is somehow special about the keys, sorry 😦

[cursive berry]

@rich sphinx thanks a bunch for the help, I even tried to use the one you use in your keymap

&mt LSHIFT A &mt LCTL S &mt LALT D &mt LGUI F   &kp G      &kp H &mt LGUI J &mt LALT K  &mt RCTRL L  &mt RSHFT SEMI

but nope, not working :/

[cursive berry]

from this branch this might be interesting, when holding &hm LGUI F and tapping with different speed &hms LSHFT A the output can be:

• afafafafa (if quick tapping a and holding f) - unexpected IMHO to see f in the output
• FafaF the F become capitalized - unexpected to see both f and F in the output
• select all (aka cmd+a) - expected

the same happen with the other half

is this some useful info? @rich sphinx

[rich sphinx]

sorry, its strange you get the f output at all - does that also happen with &mt instead of your config?

also, you can remove the quick-tap if its 0, you probably don't want that

[rich sphinx]

Maybe starting clean instead of trying to port over from qmk might also help, just build it out step by step so you exactly know where things go wrong

[cursive berry]

good point!

I reduced the keymap to what I believe is the bare minimum:

/*
 * Copyright (c) 2020 The ZMK Contributors
 *
 * SPDX-License-Identifier: MIT
 */

#include <behaviors.dtsi>
#include <dt-bindings/zmk/bt.h>
#include <dt-bindings/zmk/keys.h>

// Layers

/ {

    keymap {
        compatible = "zmk,keymap";

        default {
        bindings = <
                &kp Q           &kp W           &kp E       &kp R        &kp T                                &kp Y       &kp U         &kp I             &kp O        &kp P
                &mt LSHFT A     &mt LCTRL S     &mt LALT D  &mt LGUI F   &kp G                                &kp H       &mt LGUI J    &mt LALT K        &mt RCTRL L  &mt RSHFT SEMI
                &kp Z           &kp X           &kp C       &kp V        &kp B          &bt BT_PRV   &kp A    &kp N       &kp M         &kp COMMA         &kp DOT      &kp FSLH
                                                &kp W       &kp TAB      &kp SPACE                            &kp ENTER   &kp G         &kp BACKSPACE
        >;

        sensor-bindings = <&inc_dec_kp C_VOL_DN C_VOL_UP &inc_dec_kp DOWN UP>;
        };
    };
};

and still same problem and behaviour as described [here](#1380957725940383794 message)

[cursive berry]

I also tried to add hml and hmr as reccomended in the zmk doc, (see implemetation here ) but same problem 😦

[feral sedge]

!logging

[marsh compass]

https://zmk.dev/docs/development/usb-logging

[feral sedge]

logging should allow you to examine the exact timing and resolution of the hold-tap keys you're pressing
it's a lot to parse through, but doing so will allow you to determine what is going wrong

[cursive berry]

good tip, I just did the following test run with this keymap:

-connected the keyboard with usb
-hold cmd/f
-tap tab
-hold shift/a
the app switch on mac closed

attached the logs

I'll review them in detail tomorrow, hoping I'll find something interesting

[cursive berry]

maybe the following logs are clearer if someone has time to have a look, I tried to separate them by key sequence

• holding cmd/f
• tapping tab while holding cmd/f
• holding cmd/f while trying to hold shift/a

probably the most interesting part is the last one, where pressing shift/a immediately set 1,3 to off

[00:26:41.179,138] <dbg> zmk: kscan_matrix_read: Sending event at 1,0 state on
[00:26:41.179,199] <dbg> zmk: kscan_matrix_read: Sending event at 1,3 state off

and 1,3 is exactly cmd/f

it also seems that when I hold shift/a on the left side I cannot capitalize any of the key in that row, and the log don't detect anything (no new logs)

[cursive berry]

moving the full homerow mod on the first row works too

I tried to close the switch from the MCU directly

meaning:

• I closed the pin between row1 and col3 (until hold cmd is recognized)
• I tap TAB and I see the app switch
• I closed the pin between row1 and col0 to reproduce shift

but as soon as I close the circuit between row1 and col0 the app switch disappear

here the sequence from keyevent in karabiner element:

[
  {
    "type": "down",
    "name": {"key_code":"left_command"},
    "usagePage": "7 (0x0007)",
    "usage": "227 (0x00e3)",
    "misc": "flags left_command"
  },
  {
    "type": "down",
    "name": {"key_code":"tab"},
    "usagePage": "7 (0x0007)",
    "usage": "43 (0x002b)",
    "misc": "flags left_command"
  },
  {
    "type": "up",
    "name": {"key_code":"tab"},
    "usagePage": "7 (0x0007)",
    "usage": "43 (0x002b)",
    "misc": "flags left_command"
  },
  {
    "type": "down",
    "name": {"key_code":"a"},
    "usagePage": "7 (0x0007)",
    "usage": "4 (0x0004)",
    "misc": "flags left_command"
  },
  {
    "type": "up",
    "name": {"key_code":"left_command"},
    "usagePage": "7 (0x0007)",
    "usage": "227 (0x00e3)",
    "misc": ""
  },
  {
    "type": "down",
    "name": {"key_code":"f"},
    "usagePage": "7 (0x0007)",
    "usage": "9 (0x0009)",
    "misc": ""
  },
  {
    "type": "up",
    "name": {"key_code":"a"},
    "usagePage": "7 (0x0007)",
    "usage": "4 (0x0004)",
    "misc": ""
  }
]

could it be an issue/defect of the mcu itself? 🤔

[rich sphinx]

wild guess, but close all the software on your mac like karabiner and try again - also make sure macos has no modifiers mapped to diffenent modifiers

(although if modifiers would have been mapped it would not work on a different row)

[cursive berry]

I tried but nothing and as you said it if that was the problem it would not work on other row

the issue seems to be isolated to the pin 024-031 (D5 D21) and 024-115(D5 D18) when they are both closed together (I even tried to remove the mcu from the board and close the contact of only these pins)

this is the board I'm using

I even tried to have a look at the the dtsi file and use a different notation for the gpios but nope https://github.com/BitRulez/zmk-config/commit/f8944d0144be838cc70143b246501373fc018f06

here is my mcu schema for when the keyboard was wired, and on the right the new wireless board

[rich sphinx]

I ever only used nice nanos, puchi bles and xiaos, so I can't speak of the quality of your board - If you really think that is the issue you could try botching the pins to a free pin and change the pin assignment (or try a different mcu).

is the mcu socketed?

[cursive berry]

yes socketed

[rich sphinx]

ok, then we can at least rule out wild desolder error 😄 I guess you went with zmk because you wanted wireless, but maybe you could get some affordable rp2040 based mcus to test it with zmk without wireless (if your board allows for the right communication with zmk wired splits, never used that so you will have to read up on it in the wiki)

[cursive berry]

Good suggestion, I think I will try to ask a friend if he can lend me his nice!nano and see if the issue persist or not 😭

Worst worst case, I'll try to re-map my muscle memory and move the shift somewhere else

Also not sure what you mean with botching the pins, I'll google it now

[rich sphinx]

basically you would take a cable and connect the pin to a free pin - then on the keypress both pins would fire, but you would ignore the original pin in zmk and replace it with your new pin

[cursive berry]

I think I understood, so basically I'll connect pin p0.24/D5 to a free pin, for example p1.11/D14 with a cable

And remap in the dtsi row 1 to d14?

[rich sphinx]

yeah

[cursive berry]

Let's see, somehow I truly hope this will solve the issue 🤣
thanks for the suggestions and support, highly appreciated

[rich sphinx]

oh and make sure to use a low temp on your soldering iron 🙂 nice!nano recommends 270 to 300 degrees c

[cursive berry]

I jumped D5 (row1) to D14, and changed the dtsi file, to reflect the change in row-gpios, if I don't connect the cable between the 2 pin as expected row 1 doesn't work, when I connect pin D5 and D14 with a wire, the row 1 started to work again as expected

however, even with row1 on D14, home row doesn't work as it should 😢

as soon as I tap or hold shift/a on row1, the cmd change from down to up

I get "Sending event at 1,0 state on" (from shift/a) and immediatly after I get "Sending event at 1,3 state off" which is cmd/f 😔

can I assume row 1 is not the problem and that the problem can come from column0?

I'm planning on botching the pins of column0 now

but even if that doesn't work, I really don't know what elso I can do on the mcu ahaha

nothing, after reverting row1 and moving column0 to D14 same issue.

I will now try to botching both the pin of row 1 and col0 and see

nope, again same issue even with both row1 and col0 moved to 2 other pins 😦 I'm so confused...

[rich sphinx]

uh yeah sounds really weird - at this point I would point to the "try a different mcu" idea 🙃

[feral sedge]

I wonder if require-prior-idle-ms is interfering with your hold-tap, or if something odd is happening with hold-trigger-on-release.

Your value for RPI is quite high (mine is set to 20, but my tapping-term-ms is also only 150)

[feral sedge]

well, I wasn't able to replicate your near-immediate key releases
maybe it is a hardware problem

[rich sphinx]

One more thing I could think of would be a ghosting problem on the row.

Do other key combinations of home row mods work? Like cmd+alt+something?