Shift Keys Not Working After Logout/Login Cycle of KDE 5 Plasma

On a Lenovo Thinkpad E575 AMD A10 with openSUSE 15.0 Leap.

I am encountering some strange behavior with my shift keys on KDE 5 Plasma (Frameworks 5.45.0). In short, they work the first time I login to KDE 5, but if I log out and log back in, they do not work. Interestingly, if the CapsLock key is active, the shift keys will work normally, but once CapsLock is off, they stop working. A reboot fixes this, and the shift keys will work at the next KDE 5 login.

If I boot and login to Trinity Desktop Environment (TDE R14.0.4), the shift keys work very briefly as the desktop starts up. Once the desktop has completed it’s start up, the shift keys stop functioning, unless the CapsLock key is pressed. When I then logout of TDE and into KDE 5, the shift keys are not functional.

In all cases, the shift keys continue to work in the login screen and other desktops (IceWM, TWM and Enlightenment) and on the virtual terminals (Ctl+Alt+F1-F6). That is, I can have non-functional shift keys in KDE 5 and have functioning keys by simply switching to a virtual terminal.

I have tride the SDDM, lightDM and XDM display managers and there is no change in behavior. Neither does updating to Kernel 4.17.12 help.

I am very curious if anyone has encountered similar behavior, has ideas as to the why/how this is happening or ides for further troubleshooting.

Here’s an example of how a session goes:

Boot.
Login to KDE 5 -> shift keys work normally.
Logout.
Login to KDE 5 again -> neither shift key works by itself. If the Capslock is active, they work.
Logout.
Login to Enlightement -> shift keys work normally.
Logout.
Login to IceWM -> shift keys work normally.
Logout.
Login to Tiny Window Manager (TWM) -> shift keys work normally.
Logout.
Login to KDE 5 -> shift keys don’t work unless CapsLock is active.

Reboot.
Login to Trinity Desktop Environment (TDE) -> shift keys do not work unless CapsLock is on.
Logout.
Login to KDE 5 -> shift keys don’t work.
Switch to Virtual Terminal -> shift keys working fine.
Logout.
Login to Enlightenment -> shift keys work fine.
End.

Whilst exploring further, I’ve found that the events reported by xev are different when the shift keys work vs. when they don’t.

$ xev -event keyboard

Working shift key xev output:

KeyPress event, serial 28, synthetic NO, window 0x2800001,
    root 0x5ff, subw 0x0, time 96553481, (161,67), root:(2081,102),
    state 0x10, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x2800001,
    root 0x5ff, subw 0x0, time 96556069, (161,67), root:(2081,102),
    state 0x11, keycode 61 (keysym 0x3f, question), same_screen YES,
    XLookupString gives 1 bytes: (3f) "?"
    XmbLookupString gives 1 bytes: (3f) "?"
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2800001,
    root 0x5ff, subw 0x0, time 96556209, (161,67), root:(2081,102),
    state 0x11, keycode 61 (keysym 0x3f, question), same_screen YES,
    XLookupString gives 1 bytes: (3f) "?"
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2800001,
    root 0x5ff, subw 0x0, time 96558345, (161,67), root:(2081,102),
    state 0x11, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Non working shift key xev output:

KeyPress event, serial 29, synthetic NO, window 0x9600001,
    root 0x5f0, subw 0x0, time 35874412, (156,114), root:(160,652),
    state 0x0, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeymapNotify event, serial 29, synthetic NO, window 0x0,
    keys:  4294967280 0   0   0   0   0   0   64  0   0   0   0   0   0   0   0
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

KeyRelease event, serial 29, synthetic NO, window 0x9600001,
    root 0x5f0, subw 0x0, time 35879077, (156,114), root:(160,652),
    state 0x1, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Non working shift key xev output when CapsLock is pressed:

KeyPress event, serial 29, synthetic NO, window 0x9600001,
    root 0x5f0, subw 0x0, time 35894570, (104,84), root:(108,622),
    state 0x0, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x9600001,
    root 0x5f0, subw 0x0, time 35894701, (104,84), root:(108,622),
    state 0x2, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 29, synthetic NO, window 0x9600001,
    root 0x5f0, subw 0x0, time 35896643, (104,84), root:(108,622),
    state 0x2, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 29, synthetic NO, window 0x9600001,
    root 0x5f0, subw 0x0, time 35897584, (104,84), root:(108,622),
    state 0x3, keycode 61 (keysym 0x3f, question), same_screen YES,
    XLookupString gives 1 bytes: (3f) "?"
    XmbLookupString gives 1 bytes: (3f) "?"
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x9600001,
    root 0x5f0, subw 0x0, time 35897744, (104,84), root:(108,622),
    state 0x3, keycode 61 (keysym 0x3f, question), same_screen YES,
    XLookupString gives 1 bytes: (3f) "?"
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x9600001,
    root 0x5f0, subw 0x0, time 35898560, (104,84), root:(108,622),
    state 0x3, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 29, synthetic NO, window 0x9600001,
    root 0x5f0, subw 0x0, time 35899994, (104,84), root:(108,622),
    state 0x2, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x9600001,
    root 0x5f0, subw 0x0, time 35900110, (104,84), root:(108,622),
    state 0x2, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

I read (https://superuser.com/questions/1331249/linux-what-is-stealing-my-keypress-combination) that it might be that some application is ‘stealing’ the keypress events. So, I started looking at what was running in common between the malfunction desktops. Using a combination of ps and xlsclients I stumbled on the Clementine music player as the common denominator. Turns out I had a shortcut <Shift + F12> for Show/Hide. Indeed, I vaguely recall putting that in some time (years?) back. As soon as I changed that shortcut to something other than Shift, all my shift keys started working again.

I noticed that Clementine registers itself to handle global short cuts. When it starts up from a terminal it prints this message (along with others):

DEBUG QxtGlobalShortcutBackend:32   registering

Unfortunately, I don’t know much about how X/KWin/Qt interact as far as keyboard handling and message passing go. So, I’m not sure if this is a bug in Clementine, Xorg, the Desktops, or the keyboard drivers (libinput/evdev). Or if it’s related to the hardware itself - certainly a possibility.

I was able to reproduce this with a Thinkpad 565 as well, but I’d be interested to hear if anyone else can reproduce it.

A few other links that were helpful:
https://www.dell.com/community/Linux-Developer-Systems/XPS-13-2015-Tab-key-on-keyboard-stops-working/td-p/4636810
https://medium.com/@damko/a-simple-humble-but-comprehensive-guide-to-xkb-for-linux-6f1ad5e13450
https://forum.kde.org/viewtopic.php?t=130038
https://www.kubuntuforums.net/archive/index.php/t-70974.html
-ARA

Thanks for that follow up post. It is interesting reading.