I need some help to test if this is a KDE bug.
I am trying to debug my ctrl+r. For some reasons ctrl+r just doesn’t work on any KDE colemak layouts, and ctrl+shift+r took over its functionality (browser refresh, vim keymap, terminal shortcuts, etc).
In tty using loadkeys mod-dh-ansi-us, ctrl+r works fine.
I tried killing processes, including plasmashell to test if a process is holding the shortcut, but does not seems to be related.
Steps:
Go to System Settings -> Keyboard -> Layouts -> check Configure layouts -> Select any Colemak Variant -> Apply First -> Preview
Within preview, press
ctrl+r to see if it works, R = S key for qwerty.In my case, the
r key wont work when ctrl is held.
or test with cat for ^R output in terminal
or test with vim/neovim, ^R = redo.
Below are my settings:
Operating System: Arch Linux
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.0
Kernel Version: 6.9.1-arch1-1 (64-bit)
Graphics Platform: X11
System Locale: LANG=en_US.UTF-8
VC Keymap: us
X11 Layout: us
X11 Model: pc104
X11 Variant: colemak_dh
setxkbmap -v 9
Setting verbose level to 9
locale is C
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules: evdev
model: pc104
layout: us
variant: colemak_dh
Trying to build keymap using the following components:
keycodes: evdev+aliases(qwerty)
types: complete
compat: complete
symbols: pc+us(colemak_dh)+inet(evdev)
geometry: pc(pc104)
My Current work around is to install 3rd party layouts from
DreymaR/BigBagKbdTrixXKB
sudo setxkbmap -model pc104angle -layout us -variant cmk_ed_us -option "misc:cmk_curl_dh"
However this workaround causes a problem for me with fcitx5, I would like to know if this is a KDE issue, then report it to get it fixed.