Summary: | Rapid flickering in locked screen -- makes it difficult to unlock | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Michael Pyne <mpyne> |
Component: | effects-various | Assignee: | 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: | http://commits.kde.org/kde-workspace/d62db3816177f4b92a240a0e1533d00600db80b2 | Version Fixed In: | 4.10 |
Sentry Crash Report: |
Description
Michael Pyne
2012-07-15 19:29:31 UTC
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. D'OOOH! How embarrassing ... https://git.reviewboard.kde.org/r/105585/ 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 |