Bug 303579

Summary: Rapid flickering in locked screen -- makes it difficult to unlock
Product: [Plasma] kwin Reporter: Michael Pyne <mpyne>
Component: effects-variousAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal Keywords: regression
Priority: NOR Flags: thomas.luebking: ReviewRequest+
Version: git master   
Target Milestone: 4.10   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In: 4.10
Sentry Crash Report:

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
====================
kwin4_effect_blurEnabled=true
kwin4_effect_coverswitchEnabled=true
kwin4_effect_cubeEnabled=true
kwin4_effect_cubeslideEnabled=true
kwin4_effect_desktopgridEnabled=true
kwin4_effect_dialogparentEnabled=true
kwin4_effect_diminactiveEnabled=true
kwin4_effect_dimscreenEnabled=true
kwin4_effect_flipswitchEnabled=true
kwin4_effect_highlightwindowEnabled=true
kwin4_effect_loginEnabled=true
kwin4_effect_logoutEnabled=true
kwin4_effect_minimizeanimationEnabled=true
kwin4_effect_outlineEnabled=true
kwin4_effect_presentwindowsEnabled=true
kwin4_effect_slidingpopupsEnabled=true
kwin4_effect_startupfeedbackEnabled=true
kwin4_effect_wobblywindowsEnabled=true

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
D'OOOH!
How embarrassing ...

https://git.reviewboard.kde.org/r/105585/
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

http://commits.kde.org/kde-workspace/d62db3816177f4b92a240a0e1533d00600db80b2