Sometimes, unlocking the sessions while resuming from suspend state does not work. The screen locker shows up, the mouse is responsive, but clicking inside the input field does nothing : - no blinking cursor - typing is ignored I usually resolve it by opening a TTY, and killing "kscreenlocker_greet". Then it shows up again and works normally. Reproducible: Always Steps to Reproduce: 1. Suspend the computer 2. Resume the computer 3. On kscreenlocker_greet screen, click inside the input field Actual Results: Impossible to type in the password to unlock (no reaction) Expected Results: Type password and unlock I consider it grave as it is not only annoying, but probably many people would be left with no other issue that hard rebooting and potentially loosing data.
Which version are you using?
I have exact the same problem on Fedora 22, running KDE Plas 5.3.2. This setup has a laptop connected to a secondary screen with the laptop screen turned off.
if that problem happens, please log in to a tty, attach gdb to the kscreenlocker_greet process and get a backtrace (t a a bt) for the process. This should show us where the process is blocked.
still waiting for backtrace
Created attachment 97819 [details] gdb backtrace on x86-64 Fedora 23 ( KDE Frameworks 5.19.0, Qt 5.5.1)
In my experience, that can be a xcb/video driver deadlock, and unfortunately is being reported more often now that fedora 23's xorg-x11-drv-intel update: https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253 re-enabled dri3 by default again (f22 should still be using dri2 by default, so user in comment #2 is likely experiencing something different)
I can confirm, when I lock the screen on multiscreen X only one of the lock windows can get keyboard focus. The others can only be interacted with the mouse, clicking the password field will not give focus to it. It happens with both KWin and Icewm, both with kscreenlocker master and I tried it back with every version since 5.5, and both with the Breeze and fallback themes. Even if I comment the keyboardGrab and focus out filter, it still doesn't work.
Even if I return in KSldApp::establishGrab() I get the same behavior. I'm out of ideas, sorry, Martin, any idea?
Git commit f8043de10b5dd94b9b931a92f3aa7167188786c9 by Fabian Vogt. Committed on 01/03/2017 at 17:48. Pushed by fvogt into branch 'Plasma/5.8'. Implement manual focus on click Summary: Currently only the first created screenlock window gets focus. On clicks, no focus events are sent, which makes it impossible to input passwords. This patch now makes it possible to focus to a different screenlock window (on a different monitor, for example) using a mouse button press. This should also fix newly created screenlock windows stealing the focus of already displayed ones as only the first window gains automatic focus. Related: bug 374289 Test Plan: Locked the screen, now I can use the password input on the secondary screen as well. Reviewers: #plasma, graesslin, broulik Reviewed By: #plasma, graesslin Subscribers: hein, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D4821 M +0 -1 greeter/greeterapp.cpp M +24 -2 x11locker.cpp M +2 -0 x11locker.h https://commits.kde.org/kscreenlocker/f8043de10b5dd94b9b931a92f3aa7167188786c9
Thanks for the fix! I hope it will also solve an old erratic bug I've noticed in Mint 17.3 KDE Fr and Mageia 5.1 KDE Fr - one monitor (noticed but not reported, it's almost cosmetic once you know the workaround). Description: Unlock screen dialog box for password input does not have focus by default, and it doesn't seem to get focus on click, although it does have it after click: password typing works. But there's no text cursor in the input field, so it looks it can't get the focus. Also there's some text bleeding out of the widgets: some text is partially written where it's not supposed to have any text, near the right edge of the window box. I thought there was some poor written code somewhere that could explain that, since those defects are most basic and standard GUI feature missing. Did you noticed something weird near the code you patched? I had a quick look at your commit, it's more like a set of additional instructions than a correction of something wrong, isn't it?