|Summary||Unplug and replug Keyboard leads to unusable Keyboard for native KDE-Applications|
|Priority||P5 - None|
|Component||KDE Workspace (Plasma)|
I am using a Thinkpad T520i (Intel(R) Core(TM) i3-2310M CPU @ 2.10 GHz; 16 GiB RAM, 500 GB SSD Disk) with openSuSE Leap 42.3 (Currently Kernel 4.4.114-42-default, X.org X Server 1.118.3, KDE Framework 5.32.0, QT 5.6.2, xf86-input-libinput-0.25.1-1.1.x86_64, libinput-udev-1.5.0-3.5.x86_64, libinput10-1.5.0-3.5.x86_64) and a while ago I first encountered the problem, that native KDE-Applications don't get any keyboard input after unpluggin and replugging the keyboard (e.g. when undocking and redocking the thinkpad to a dock with an usb keyboard) Using the Thinkpad with a dock and a USB-Keyboard connected to it makes this usage quite uncomfortable. The only workaround I could find is logging out and logging in again. Then everything is working again, but as it requires me to stop my work and restart all applications this is not a feasible workaround. This only happens with KDE Applications (plasmarunner, plasmamenu, kate, konsole, etc) not with X, GTK or even simple QT Applications), all other applications just work fine with any keyboard (internal Thinkpad, external USB, virtual Keyboard application) wheres KDE applications with none of those keyboards, not even the virtual keyboard. The keyboard is also listed in the xinput output after replugging it (run from an xterm as konsole isn't taking any keyboard input anymore). The USB mouse is just working fine. So it definitely doesn't look like a hardware, driver or X problem, but like something caused by the common code used by kde applications for doing input. The Bug is probably also already present in older code as I never used an USB keyboard or the dock before I didn't encounter those problems. I even tried the workaround from the almost similar sounding bug description of BUG 988792 by running 'killall plasmashell ; kstart plasmashell' but this doesn't work for me. Neither does deactivating /etc/X11/xorg.conf.d/40-libinput.conf and using evdev driver instead of libinput as BUG 1044820 suggests as a solution/better workaround. Frankly I'm not sure which log files, config files, config settings, command output paste or other information I could provide to make tracing this bug behaviour to specific code lines easier, but If you point me in a direction, I'll provide that information gladly.