A few days ago I noticed that the lock screen feature was suffering from rapid flickering: The effect was as if the normal screensaver and a full-black backbuffer were fighting it out to be shown on screen.
Worse, even though the input window would show up as normal when a key was pressed or the mouse was moved, there was no user-visible feedback on that window of input. E.g. no Oxygen animation for moving over buttons, and no feedback in the password line edit when typing the password. During this time the input window was displayed there was no flickering, just a black screen behind the input window.
When I tried to type in the Password and hit enter to unlock as normal, it did usually work... after 10-15 seconds of no activity. This makes is highly irritating to try to lock the screen as it's not guaranteed I'd be able to get back into the desktop again! (Twice by now I've had to force a logout from a different TTY and log back in).
Since it only started a couple of days ago I've used git-bisect and I'm 99% sure the problem was introduced in commit 042d6df9bfead3c1219f3849bdbe2280fabb3188 (re-use input window, prevent destryoing it). Although I was not able to reliably reproduce issues with the flickering 100% of the time (sometimes there'd be no problem the first couple of times I locked the screen), I have not experienced this issue again after reverting that commit.
The newest KWin git version experiencing issues was: a71aefcbdc24c5859fe02f3147e835b0762bbc8a (master at the time of my testing).
Some debugging info:
kde-svn@midna /kdesvn/build/kde/kde-workspace/kwin $ kwin --replace
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
Object::connect: No such signal OrgKdeActivityManagerActivitiesInterface::presenceChanged(bool)
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV710
OpenGL version string: 2.1 Mesa 8.1-devel (git-ca8fa02)
OpenGL shading language version string: 1.30
GPU class: R700
OpenGL version: 2.1
GLSL version: 1.30
Mesa version: 8.1
X server version: 1.12.2
Linux kernel version: 3.5
Direct rendering: yes
Requires strict binding: no
GLSL shaders: yes
Texture NPOT support: yes
kde-svn@midna ~/.kde4/share/config $ grep 'kwin4_effect_\w*=true' kwinrc
If you need more details let me know, thanks.
I can confirm that this week I switched several times to a tty to kill the screenlocker
Yupp - sorry.
The screenlocker adds an unmanaged, raises it, kwin triggers ::checkInputWindowStacking(), has "old" input windows, raises them, the screenlocker doesn't like that, raises itself, kwin gets notified, thinks it's input windows should be on top ...
Testing whether the input window is mapped in ::checkInputWindowStacking() is likely sufficient but we should get trouble (do we? i've no "scrensaver" and the first thing the screenlocker trigger does is suspend compositing) with the screensaver and active fullscreen effects?!
No, "unfortunately" i did think about checking the mapping state (otherwise the desktop would likely become unusable all the time)
There must be sth. else. Gona check what.
How embarrassing ...
Git commit d62db3816177f4b92a240a0e1533d00600db80b2 by Thomas Lübking.
Committed on 16/07/2012 at 21:57.
Pushed by luebking into branch 'master'.
don't try to raise unmapped input windows
or screenedges over unmapped
causes race with kscreenlocker
M +6 -3 kwin/effects.cpp