After logging in, the first time that the "Ctrl" key is pressed has the effect that, the keyboard's NumLock indicator lamp is also cleared -- but, once only. * After the keyboard's NumLock lamp has been re-enabled, by pressing the "NumLock" key twice, further presses of the "Ctrl" key do not affect the NumLock status. Further investigation has showed that, this <Ctrl>/NumLock status behaviour begins as soon as the SDDM Splash Screen appears during the login process. This behaviour does not occur at the SDDM "choose the user and enter the user's password" screen -- pressing the <Ctrl> key here does not change the NumLock status.
With: openSUSE Tumbleweed (20170806) Plasma 5.10.4 KDE Frameworks 5.36.0 Qt 5.9.1 I don't see this behaviour. However, with: openSUSE Leap 42.3 Plasma 5.8.7 KDE Frameworks 5.32.0 Qt 5.6.2 I see an almost identical behaviour, except, it is the "Shift" key, not "Ctrl" that causes the "Numlock" indicator to change. Indeed it is not just the indicator, but the "Numlock" status itself changes, which is how I first noticed the phenomena.
openSUSE Leap 42.2 plasma5-desktop: 5.8.6-7.1 plasma-framework: 5.27.0~20160928~b115ea1.git-3.1 KDE Frameworks: 5.26.0 Qt: 5.6.1 ----------------------------------------------------- Yes, the shift key, as well as the <Ctrl> key provokes this "once-only at login" behaviour. ----------------------------------------------------- /etc/sddm.conf [General] Numlock=on /etc/sysconfig/keyboard KBD_NUMLOCK="bios" ----------------------------------------------------- Now a thought: the BIOS on this system (old, not UEFI) doesn't have a NumLock setting . . . I'll set the SysConfig KBD_NUMLOCK value to "yes" and report in a minute or two.
Setting the SysConfig KBD_NUMLOCK value to "yes" didn't affect the KDE Plasma behaviour. Also, it didn't enable the keyboard's NumLock indicator during the Linux boot . . .
openSUSE Leap 42.3 -- UEFI Laptop -- no NumLock setting in UEFI/BIOS. plasma5-desktop: 5.8.7.1-3.1 plasma-framework: 5.32.0-4.1 KDE Frameworks: 5.32.0 Qt: 5.6.2 /etc/sddm.conf [General] Numlock=on ----------------------------------------------------- Same "once-only at login" NumLock behaviour as with the earlier Plasma5 version.
As a follow up: The keyboard is a UK "Logitech k120 Business" (USB) and in (KDE) "System Setup -> Input Devices -> Keyboard - Hardware" is set to "Logitech | Generic" Numlock on Plasma Startup is set to "Leave Unchanged" Numlock is set to "On" in the PC BIOS (Also legacy, not UEFI) /etc/sddm.conf sets Numlock=on Also, a correction to my first, Comment #1 the Ctrl key does indeed also trigger this.
System with: plasma5-desktop: 5.8.6-7.1 plasma-framework: 5.27.0~20160928~b115ea1.git-3.1 KDE Frameworks: 5.26.0 Qt: 5.6.1 Keyboard is a German Cherry CyMotion Master Linux (the "Meta" key is "Tux" + Cherry Tux sticker above the "Esc" key -- not Redmond . . . ) System Settings: NumLock on Plasma Startup: On ----------------------------------------------------- System with: plasma5-desktop: 5.8.7.1-3.1 plasma-framework: 5.32.0-4.1 KDE Frameworks: 5.32.0 Qt: 5.6.2 Lenovo G505s laptop German keyboard -- generic international 105 keys. System Settings: NumLock on Plasma Startup: On -----------------------------------------------------
Not only the <Shift> and <Ctrl> keys, also: - <Meta> -- the "Windows" key; - <AltGr> -- "Alternate Graphic".
If, * before any other of the keys mentioned above have been pressed during or after the user's login process is executing, * the <Num> (NumLock) key is pressed twice, once to "unlock" and, then again to "lock", then, * the behaviour being documented in this Bug Report does not occur.
If, in KDE "System Settings", section "Workspace", sub-section "Startup and Shutdown", module "Desktop Session Login and Logout", section "On Login", "Start with an empty session" is selected, this issue seems to not occur.
** Correction: ** This issue doesn't disappear if "Start with an empty session" is selected -- it *intermittently* doesn't occur if "Start with an empty session" is selected.
With the following KDE components (openSUSE Leap 15.0) this issue seems to have been resolved: KDE: 5.45.0 plasmashell 5.12.5 Qt: 5.9.4 Now closing this issue.