SUMMARY On plasma/wayland when configuring the German keyboard layout Neo2 the layout is permanently stuck on layer 4 and therefor completely unusable. (the layer maps most numpad functions to the main keyboard section) STEPS TO REPRODUCE 1. set layout "German (Neo 2)" in Keyboard System Settings 2. try to type anything OBSERVED RESULT Layout permanently stuck on layer 4. Need to switch to a standard layout. SOFTWARE/OS VERSIONS System: Gentoo Linux (linux 5.10.76 64bit x86) KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 Graphics Platform: Wayland ADDITIONAL INFORMATION I have had problems with Neo2 on Plasma/Wayland for years but things fully broke after updating from plasma 5.22.5 to 5.23.4. In previous versions the layout would be stuck on layer 4 on login but reset after changing any setting in the keyboard configuration menu and pressing the "apply" button. This workaround does no longer work in 5.23.4 and the layout is now permanently stuck on layer 4. On another system with Plasma/X11 I have no issues. I have restored the keyboard default settings but that did not cause any change in behavior. As a side note, when newly configuring keyboard layouts now, the Neo 2 layout shows "Map: de" (same as German standard layout) instead of "Map: neo". Don't know if this is relevant.
*** This bug has been marked as a duplicate of bug 432436 ***
This bug is a duplicate of 432436. It is not about layout changing at all.
Unfortunate typo: This bug is *not* a duplicate of 432436. It is not about layout changing at all.
Please dump your ~/.config/kxkbrc
As far as I can tell there is no difference no matter what settings I set or how many layouts I configure. ~/.config/kxkbrc [$Version] update_info=kxkb_variants.upd:split-variants [Layout] DisplayNames= LayoutList=de LayoutLoopCount=-1 Model=pc105 Options=grp:alt_space_toggle ResetOldOptions=true ShowFlag=false ShowLabel=true ShowLayoutIndicator=true ShowSingle=true SwitchMode=Global Use=true VariantList=neo
Can you try on Gnome Wayland etc.? It still might be upstream issue
I have tried with "XKB_DEFAULT_LAYOUT=de XKB_DEFAULT_VARIANT=neo sway" and this worked as intended.
(In reply to Conrad from comment #7) > I have tried with "XKB_DEFAULT_LAYOUT=de XKB_DEFAULT_VARIANT=neo sway" and > this worked as intended. Is it on Gnome?
No, sway is its own wayland compositor. "etc." sounded like that was what you were asking for. Any way to test this without having to install the whole gnome suite on my system?
You can test in VM, but if it works for Sway then it's probably something different.. Still we need a way to reproduce it, so yes, please test on VM. You can use Neon iso.
Thanks for your help so far! I tested with a newly created user just now and the problem does not occur there. Any idea where I could start looking to narrow down the cause?
Figured out the problem. It was caused by ~/.config/kcminputrc and more precisely by these lines: [Keyboard] KeyRepeat=repeat NumLock=0 RepeatDelay=600 RepeatRate=25 It must have been created by some older version of kde/plasma.
(In reply to Conrad from comment #12) > Figured out the problem. It was caused by ~/.config/kcminputrc and more > precisely by these lines: > > [Keyboard] > KeyRepeat=repeat > NumLock=0 > RepeatDelay=600 > RepeatRate=25 > > It must have been created by some older version of kde/plasma. Hmm, what exactly the key causing this? We probably need to sort it out in upgrade scripts, then..
The culprit is "NumLock=0". Removing the line or changing it to "NumLock=1" resolves the problem.
So it's probably was enough to just press NumLock to make it work?
I can't tell. My numlock is always off and I can't enable it. Probably some other problem with legacy config files.
What if you turn off NumLock on start in Keyboard > Hardware > NumLock on KDE Startup? https://forum.kde.org/viewtopic.php?t=133089 Please also check if that actually sets the NumLock option to 0 .
turn on sets it to 0, turn off sets it to 1. The problem indeed only appears when numlock is enabled.
(In reply to Conrad from comment #18) > turn on sets it to 0, turn off sets it to 1. Exactly like this, not the otherwise?
Yes, verified multiple times.
(In reply to Conrad from comment #20) > Yes, verified multiple times. IIUC, the values look inverted, no?
They do. They are written to the file like this as soon as I click the "apply" button in the system settings.
(In reply to Conrad from comment #22) > They do. They are written to the file like this as soon as I click the > "apply" button in the system settings. I have a theory then. Earlier, you could "reset" non-working layout with any change in KCM Keyboard, because that change was reset NumLock status also. Now we've got a feature that any Lock status preserves on that reconfiguration. So if initial NumLock state don't work for whatever reason, you can't reset it any more. Is it realistic enough to be a truth?
Yes, that could be what is happening here. It does however not explain why neo2 layout would become unusable if numlock is on.
(In reply to Conrad from comment #24) > It does however not explain why neo2 layout would become unusable if numlock > is on. Can you try that on Gnome/etc.? Might be something with the layout itself. Also, could anyone confirm that NumLock status inversion we talked above? It might be NumLock set in UEFI, and it interfere somehow..
I can confirm your suspicions. sway shows the same broken behavior as soon as numlock is turned on. So very likely an upstream problem. Regarding the 0/1 status in the config, this has been for years., so probably working as intended. I found this thread from 2009 that references the same settings: https://forums.gentoo.org/viewtopic-t-805441-start-0.html
(In reply to Conrad from comment #26) > I can confirm your suspicions. sway shows the same broken behavior as soon > as numlock is turned on. So very likely an upstream problem. > Please report it here then and paste the link back: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues > Regarding the 0/1 status in the config, this has been for years., so > probably working as intended. Not necessary. I don't see the reason why it's inverted, and that may be exact the same problem why you got the issue from the beginning..
Thank you for your help so far! Upstream bug has been reported here: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/300
You are welcome. So I would open another bug about inverted NumLock in the config, and close this one as Upstream.
sure, sounds good
Conrad, it would be better if you file the inverted NumLock status issue yourself - you tested it and I don't know the details. With that, closing this one.