&kp LPAR generates [LSHFT Press, ( Press, LSHFT Release, 9 Release] keycode sequence

[glenn20]

The Problem

Pressing a key mapped (&kp LPAR) to the LPAR symbol (or any other symbol key which is reached via SHIFT on a conventional keyboard) generates the following key sequence:

• LSHFT Press, ( Press, LSHFT Release, 9 Release
  • ie. the final key release event has the keycode of the unshifted key.

(tested using xev application on debian linux).

Expected keycode sequence:

• LSHFT Press, ( Press, ( Release, LSHFT Release

Impact

This leads some applications on Linux (esp. terminal applications such as Gnome Terminal and Tilix) to sometimes register the key as a 9. The misidentification does seem to be timing dependent (andf may be affected by terminal settings). Eg. the problem occurs more frequently for "shifted symbols" assigned to home row mod keys on my SYMBOLS layer.

If the output key sequence is by design (intention):

• Are there any suggested or known work arounds to mitigate the impact on applications?
• I would also be interested in understanding the reasons behind this design choice (it seems unexpected to me)

If this is not the intended behaviour, any advice on addressing this through my configuration would be very welcome.

Keyboard: Ferris Sweep (nice_nano_v2 cradio_left/right)
ZMK version: Tested with main branch latest commit 7be955ff (and over the last few months)
Computer: Debian linux 12 (bookworm) (connection via bluetooth)
Config: https://github.com/glenn20/zmk-sweep/blob/main/config/cradio.keymap

[caksoylar]

See #759 and #2334.

[glenn20]

@caksoylar Thanks for the links. It was really hard to find the right words to search in issues. Very encouraging to see PR2334 in the works. I'll mark this closed.

[glenn20]

Ah... as it turns out, the problem I identify above is not causally linked to the impact I was seeing. After applying #2334, the correct sequence of LSHFT Press, ( Press, ( Release, LSHFT Release is generated (as reported by xev), but the terminal programs continue to produce the unshifted key (9). Some of the remedies described in #759 may be the best workaround for now. Thanks @caksoylar .

[glenn20]

On further investigation... #2334 does substantially improve the issue for my non-home row keys. Those on home-row mods are still susceptible to misidentification by applications (eg. gnome-terminal).