Bug 303579 - Rapid flickering in locked screen -- makes it difficult to unlock
Summary: Rapid flickering in locked screen -- makes it difficult to unlock
Alias: None
Product: kwin
Classification: Plasma
Component: effects-various (show other bugs)
Version: git master
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: 4.10
Assignee: KWin default assignee
Keywords: regression
Depends on:
Reported: 2012-07-15 19:29 UTC by Michael Pyne
Modified: 2012-07-22 09:17 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.10
thomas.luebking: ReviewRequest+


Note You need to log in before you can comment on or make changes to this bug.
Description Michael Pyne 2012-07-15 19:29:31 UTC
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
Driver:                                 R600G
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

Enabled effects:
kde-svn@midna ~/.kde4/share/config $ grep 'kwin4_effect_\w*=true' kwinrc

If you need more details let me know, thanks.
Comment 1 Martin Flöser 2012-07-15 19:40:09 UTC
I can confirm that this week I switched several times to a tty to kill the screenlocker
Comment 2 Thomas Lübking 2012-07-15 20:11:23 UTC
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?!
Comment 3 Thomas Lübking 2012-07-15 20:14:20 UTC
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.
Comment 4 Thomas Lübking 2012-07-15 20:22:52 UTC
How embarrassing ...

Comment 5 Thomas Lübking 2012-07-22 09:17:08 UTC
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
REVIEW: 105585
FIXED-IN: 4.10

M  +6    -3    kwin/effects.cpp