| Summary: | screensaver (blank) - screen contents are exposed for a short time before unlocking | ||
|---|---|---|---|
| Product: | [Unmaintained] kscreensaver | Reporter: | Unknown <null> |
| Component: | general | Assignee: | kscreensaver bugs tracking <kscreensaver-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | andresbajotierra, becker.holly, decha, jaak, kde, kde, kwin-bugs-null, m.krasilnikov, markg85, mathias, mrgrim, oliver.henshaw, onno, peter, tim, xenoterracide, yester64, zanetu, zerg2000-bugs.kde.org |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Desktop shown under unlock window | ||
|
Description
Unknown
2009-02-07 00:24:38 UTC
This happens for me in kde 4.2.2 no matter the screen saver selection. It does seem to be specific to compositing being turned on for me. This could be related to bug 179924. Thanks Hmm, I'm not sure I see the relation. Do you mind elaborating a little? 179924 seems to refer to popups or other always on top type windows covering the screensaver. This bug is referring to the entire desktop being visible for a split second when activating the unlock dialog (via activity e.g. moving the mouse or hitting a keyboard key) right before the dialog shows. Usually, I see the screensaver running. I move my mouse, and the entire desktop appears very briefly, then the screen turns black and the unlock diaglog appears over the black screen. Several seconds later (if you do not immediately unlock) the screensaver appears again under the unlock dialog. So ignoring the unlock dialog itself and paying attention to whats behind it the order of events is: 1) screensaver merrily going about its business - mouse moved - 2) desktp displayed for a split second (bad part) 3) blank screen for a few seconds 3) screensaver comes back The ideal situation would be no change whatsoever. The unlock dialog would just appear on top of the screensaver without interruption. I hope that made it more clear and not less so. i don't suppose you have "allow widgets on screen saver" enabled? I do not Same problem here with KDE 4.3.3. Sometimes whole desktop becomes visible under unlock dialog and does not disappear (it is not clickable however), sometimes only wallpaper is visible. I alway use "show the desktop" before locking screen because of this bug. If I remember correctly it was present in KDE 3.5.x too. The thing that is visible for a fraction of a second is probably root window. I have wallpaper set on root window with 'feh --bg-scale "file.jpg"' for conky pseudo-transparency and when I change it to something else then it is displayed, not wallpaper from plasma. I was able to reproduce "whole desktop visible under unlock dialog" but this bug was only present for about 10 seconds after locking screen, so it is not that bad. I was unable to see any running aplications after about 10 seconds - only that root window. Put Your system under load (start one instance of glxgears for every CPU core) to reproduce. Created attachment 38746 [details]
Desktop shown under unlock window
Today I have locked a screen with alt+control+l and returned 5 minutes later. I have moved my mouse and whole desktop appeared under unlock window as seen on this "screenshot". Desktop was static - conky window and clock didn't update and I was unable to perform any action on the desktop. As long as I have been moving my mouse/writing something on keybord, the desktop was visible. After pressing "cancel" the screen went blank and desktop didn't appear under unlock window anymore.
System: Arch Linux 64 bit, KDE 4.3.3
Settings:
- Screenserver: Blank Screen
- Start automatically after 4 min
- Require password to stop after 10 seconds
Please vote on this bug if You are affected. Sorry for fragmented comments.
What you described is a different symptom from the original bug report and what I experience, and it may be another bug altogether worthy of its own report. The symptom the original reporter and I experience is a brief sub second flicker of the desktop between input and the unlock dialog appearing. It is very quick, but a digital camera shooting video would be able to capture a frame or two of the desktop contents during the brief period the desktop is visible. You are right, "between input and the unlock dialog appearing" for fraction of a second I can see only root window (wallpaper), not window contents. And the other bug is bug #162178 so I will move there. :} sidux users are seeing this as well, so I'm going to follow this bug. I think it's a security/privacy risk. I should say that "sidux" means Debian sid, KDE 4.3.4 *** Bug 214432 has been marked as a duplicate of this bug. *** possibly related to bug 162178, though the timing is different. regarding the original bug report: this is due to the un/redirection (the screensaver runs as FS window, thus the content is "unredirected" what basically means that compositing is turned off for that window and it's painted diretctly onto the screen to save cpu cycles, pretty helpful for games or videos) whenever another window pops up and is stacked above the FS window it's re-redirected (basically to paint the shadows onto it ;-) what causes a) flicker (there're some reports) b) this bug you can turn unredirection off by adding UnredirectFullscreen=true to ~/.kde[4]/config/share/kwinrc, [Compositing] group, but that will have a performance impact for FS windows (depending on the TextureFromPixmap support of your GPU/driver) i suggest (for performance and security reasons) to suspend compositing before running the screenlocker and (in case) resume it when the the screen gets unlocked there seems to be no cross-wm way to suspend compositing. kwin only has a global compositing toggle function, which is prone to at least two race conditions (one is two applications simultaneously trying to change the state, the other is one application exiting and re-enabling compositing while the other one is still running). the proper solution would be adding a window manager hint and having the compositing disabled as long as any such window is mapped. the *real* proper solution would be of course fixing the underlying problem (bug 177495). or rather, working it around at a lower level. would it be technically possible to make the re-redirection seem atomic by having the window both mapped and composited for a moment rather than neither of the two? composite a screenshot of the current mapping before removing it or something like that. another possible solution is to not unredirect screensavers. That would be fine for the cases of a black screensaver, but would have performance impact on OpenGL screensavers. Of course fixing the flicker bug would be better. I tried to investigate it some time ago (before 4.2), but obviously I failed. Btw. I am not sure if the issue is only triggered by the unredirection. I have unredirection disabled and nevertheless see sometimes on wakeup notifications above the screensaver for a very short period of time, but I think there is another bug report for that.... Are we talking about opengl compositing? Bc I have it disabled and still experience the issue. which issue? the original one (interim "flicker" visibility) or the one from comments #7/#8 (which should be a different bug) Read initial comment and #7/#8 few times but can't spot the difference. I sometimes see desktop contents when my screen is locked. the original report is about the desktop showing up for a very short moment when the screensaver gets re-redirected as it looses the "fullscreen on top" state #7 and esp. #8 are apparently about the desktop appearing and not going away (unless esc is pressed) what's either a bug in kwin, kscreensaver or X11 / the gpu driver you actually cannot suffer from the re-redirection wink-of-an-eye thing if you turned compositing off (as w/o compositing there's nothing to un- and later re-redirect) Thanks for clarifying. I will update the bug as soon as I see the issue again. Actually I haven't seen it for a while now... *** Bug 226395 has been marked as a duplicate of this bug. *** *** Bug 255051 has been marked as a duplicate of this bug. *** I sure do wish this security bug would get fixed soon. (In reply to comment #25) > I sure do wish this security bug would get fixed soon. Well its almost 2 years now it seems. I'm seeing symptoms of bug 249417, which has been closed as a duplicate of this one. Sometimes when I lock my screen, the entire desktop is visible, but not able to be interacted with. I don't think the system was under heavy load (firefox, kopete, dolphin, and sublime-text, load average from top < 1). Arch Linux, kernel Linux host 3.4.7-1-ARCH #1 SMP PREEMPT Sun Jul 29 22:02:56 CEST 2012 x86_64 GNU/Linux KDE 4.9.0 KDE 4.9.2 is still affected (Arch Linux) 4.8.5-0ubuntu0.1 is also affected (Kubuntu) All screensavers from kdeartwork are also affected. (Asciiquarium, OpenGL screensavers, Polygons, ...). The Polygons screensaver is also a bit weird. When you try to unlock, a password dialog will appear. If you cancel that, the polygons screensaver continues, but without clearing the screen. (bug or feature?). KDE 4.9.3 still affected here by the shorty-visible-desktop-before-passwd-dialogue-bug (only if desktop effects are active) since 4.8 even the worse symptom occures from time to time on my box (=desktop visible all the time while the dialogue asks for the password, though no desktop interaction possible) new implementation in 4.10 OP is dupe also all "screensaver exposes desktop" issues should be resolved in 4.10 *** This bug has been marked as a duplicate of bug 291078 *** *** Bug 258015 has been marked as a duplicate of this bug. *** |