You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
@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.
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 .
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).
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(tested using
xev
application on debian linux).Expected keycode sequence:
LSHFT
Press,(
Press,(
Release,LSHFT
ReleaseImpact
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):
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 commit7be955ff
(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
The text was updated successfully, but these errors were encountered: