Bug 305270 - Lock screen reveals desktop
Summary: Lock screen reveals desktop
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: 4.9.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-16 15:48 UTC by rgrout
Modified: 2016-10-30 08:00 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rgrout 2012-08-16 15:48:15 UTC
Running on Intel Sandy Bridge Graphics (Intel 3000), the lock screen periodically reveals the desktop.  Noticed most often when desktop is waken from sleep.

I feel that it is related to the intel graphics driver.  Someone else on the ArchLinux forums has noticed the same issue on intel gfx hardware.
https://bbs.archlinux.org/viewtopic.php?pid=1147350#p1147350

I'm at a loss at how to figure out where to find more info for this bug.  I do know that it was never observed on KDE 4.8.x

Reproducible: Couldn't Reproduce

Steps to Reproduce:
1. Suspend a lot of times
2. Pray the bug reveals itself
3. speculate about what might have caused the error
Actual Results:  
Sometimes the desktop is revealed, sometimes it is not.

Expected Results:  
The desktop should never be revealed when locked.

At first I thought it was this bug
https://bugs.kde.org/show_bug.cgi?id=291078

But it happens when the blur effect is disabled.
Comment 1 Martin Flöser 2012-08-16 16:29:05 UTC
What do you mean with the desktop is revealed? Has the lock screen not started or is the screen locked but you see parts of the desktop?

What screensaver are you using?
Do you use unredirection of fullscreen windows (desktop effect settings, third tab, suspend desktop effects for fullscreen windows)?
Comment 2 Thomas Lübking 2012-08-16 18:24:24 UTC
I can reproduce that here as well (nvidia, blur is NOT crucial but seems to raise probabilities)

Apparent conditions:
- happens only once after "kwin --replace" (?)
- better chance to reproduce by changing the current desktop (-> full repaint -> glXSwapBuffers?)
- doing so i see the FORMER desktop until i actually exit the locker when the current one appears immediately (w/o animation)
- move to VT1 do do some xwinwinfo / xprop magic, move back, figure screen is black and showing / hiding the popup will no longer expose the desktop.
- not reproduced (so far) with page flipping disabled (also not with blurring enabled)


a) i think this is a dupe of #291078
b) it seems to be the backbuffer which is "somehow" kept by the screenlocker (possibly because it grabs the entire server?)
Comment 3 rgrout 2012-08-16 18:27:57 UTC
When I say the desktop is revealed, I mean that the desktop is locked (evidenced by the lock screen password dialog), yet the entire desktop is revealed.  I am using the Blank Screen screensaver (it is the only one I had installed).  The "Suspend Desktop Effects for fullscreen windows" option is enabled.
Comment 4 Martin Flöser 2012-08-16 18:29:11 UTC
Just for the record: I have never experienced this issue so far with radeon. But I also use the plasma-overlay
Comment 5 Thomas Lübking 2012-08-16 18:34:18 UTC
>  The "Suspend Desktop Effects for fullscreen windows" option is enabled.
So the region ought not to be painted by the compositor at all (unlike in my setup but the different trigger will lead to the same result of being the backbuffer in the locker buffer)

-> can you try checking what happens when you change VDs right before (hopefully) causing this (trying to get a better hint on what the locker displays there)
Comment 6 rgrout 2012-08-16 18:40:20 UTC
If I change VD right before locking:
1. The screen goes blank
2. If I move the mouse or press a key, the desktop flashes on the screen briefly along with the the password prompt dialog.  It is very brief, but it is long enough for me to clearly recognize my desktop.

I think the password prompt dialog is triggering the desktop flashing on the screen. It only happens the first time the password prompt is displayed, all subsequent displays, there is no flashing of the desktop.
Comment 7 Jörg Afflerbach 2012-09-18 10:45:40 UTC
Same here on KDE 4.9.1/openSUSE 12.2 with Intel graphics ("Intel Arrandale Integrated Graphics Controller"), I’ve seen this behaviour with older KDE releases as well. So, it’s not a new problem.
Comment 8 Onno Molenkamp 2012-09-25 09:29:12 UTC
Same here on KDE 4.8.5 (openSUSE 12.2) with the radeon driver.
Comment 9 Lastique 2012-12-28 06:41:00 UTC
I have the same problem on Kubuntu 12.04, KDE 4.9.4 - the desktop is shown below the password prompt dialog. I'm using ATI Catalyst drivers. In my case, I'm not doing kwin --replace or anything special to trigger it, it just happens sometimes (not always) after the screen turns on. I do not put the computer to sleep, I just set up the screen to be switched off after the timeout. The screen saver is disabled.
Comment 10 Andriy Gapon 2013-02-06 12:32:24 UTC
I can confirm this issue on FreeBSD with KDE 4.9.5.

Some facts/observations:
- I have intel driver with kms (ivb hardware)
- sometimes, very rarely, the desktop stays revealed "forever"
- every time the above doesn't happen the desktop flashes for a very brief moment before the background is blacked out and only the password dialog is visible

[drum roll]

- it seems that the problem occurs only if "Fade" desktop effect is enabled (please do not confuse with "Fade Desktop")

It would be interesting to see if other reporters observe the same about the Fade effect.
That might give some clues.
Comment 11 Eric Griffith 2013-03-06 20:46:22 UTC
Best guess, Martin, KDE is hitting the same problem that the Gnome guys hit. Suspend/Lock is done in the wrong order.

Arch Linux, x64, kde 4.10.1

Suspend On lid close
Lock screen on suspend. 

1) At Desktop
2) Close lid
3) KDE initiates suspend.
4) Sleeps...
5) Lid opens
6) Laptop wakes up from sleep
7) Desktop is displayed for a half second while plasma checks to see if its supposed to lock the screen (this check takes a non-zero amount of time)
8) If yes, screenlocker is called. If no, then desktop stays displayed.

Assuming that is correct, then the ordering just needs to be re-arranged. It should go:

1) At desktop
2) Close lid
3) Plasma checks to what needs to be done. If it needs to lock and suspend, then it needs to call lock first, and then suspend from the screenlocker.
4) Sleeps
5) Wake up
6) If needed to be locked then the running process will be the screenlocker not the desktop shell
Comment 12 Eric Griffith 2013-03-06 20:52:30 UTC
Additional notes to my comment above.

Unredirect full screen windows is NOT enabled for me, so its not a issue of the compositor (kwin) not being able to have full control.

The bug does NOT occur (furthering my idea above) if i explictly lock the screen before I close the lid. 

Menu -> Lock -> Lockscreen appears -> Close lid -> Suspend kicks in -> Wait to make sure laptop is suspended -> Open lid -> Desktop is NOT flashed, the display goes right to the screenlocker as it should.
Comment 13 Thomas Lübking 2013-03-06 21:25:22 UTC
You're describing different bug #313123
Comment 14 Eric Griffith 2013-03-06 21:34:06 UTC
Noted, thank you Thomas.
Comment 15 Martin Flöser 2015-01-13 08:50:43 UTC
this bug report hasn't seen any comments for almost two years, so I'm wondering whether people are still experiencing the problem?
Comment 16 Eric Griffith 2015-01-13 18:05:03 UTC
Before a botched upgrade to plasma2, more on that below, on Fedora (latest KDE4 packages) I was still suffering from this, Martin. I saw your blogpost about this getting fixed in 5.2 and am eagerily awaiting the beta to hit dvratil's copr. 

Speaking of the botched upgrade... Martin, question for you: was there a known bug in kwin or some other part of the compositing path that made it crash consistently somewhere between 5.1.2 and the 5.2 beta? I'm asking because dvratil and I got kwin to consistently crash (me on Intel Sandy Bridge with mesa 10.4.1 x64, him im not sure on) if we tried to log in to KDE with compositing enabled OR if we activated compositing from Settings after we were already logged in. 

Haven't made a bug report about it yet as the 5.2 beta is supposed to get packaged in his copr later this week, and im waiting to see if it automagically gets fixed from that update. If its not i'll make a bug about it then.
Comment 17 Thomas Lübking 2015-01-13 19:51:19 UTC
Crash like "with a backtrace" or like "black screen"?
In the latter case: likely (and fixed) - in the former case: hard to say w/o the backtrace.
Comment 18 Eric Griffith 2015-01-14 04:11:23 UTC
No backrace, least none that got presented to me. In the case of it crashing on login: Splash screen would come up, progress bar would move, it would get about 80% done and then hang there forever. I'm assuming that the last 80% or so is the splash waiting for a "go" signal from Kwin which never came because kwin immediately crashed upon trying to run the compositing path. 

In the case of enabling compositing after already being logged: everything would be working fine, you'd enable compositing and then everything except the mouse pointer would freeze. No input, no sound, no nothing. Could move the mouse pointer but no clicks or drags or anything would be detected, no keyboard input worked (including switching to a console) and the only solution was a hard shutdown.
Comment 19 Martin Flöser 2015-01-14 06:55:54 UTC
> No backrace, least none that got presented to me. In the case of it crashing
> on login: Splash screen would come up, progress bar would move, it would
> get about 80% done and then hang there forever. I'm assuming that the last
> 80% or so is the splash waiting for a "go" signal from Kwin which never
> came because kwin immediately crashed upon trying to run the compositing
> path.

That's bug #342582 - worked around in the beta release (I ensured that 
tarballs are recreated with the patch)
Comment 20 Thomas Lübking 2015-01-14 12:34:19 UTC
not necessarily - the 2nd half describes a kernel halt when starting the compositor, ie. the problem is in the kernel module.

-> please attach:
~/.kde/share/config/kwinrc
/var/log/Xorg.0.log
output of "lspci"
output of "glxinfo"

WARNING!
calling "glxinfo" might cause the kernel to halt!
Comment 21 Eric Griffith 2015-01-15 06:11:05 UTC
Installing the beta now so we'll see what happens. If its still messed up I'll make a bug report and attach the above
Comment 22 Martin Flöser 2016-10-30 08:00:07 UTC
As the lock screen architecture changed a lot between 2012 and today I mark the bug as unmaintained. The versions just don't match any more, the actual problem cannot be present in the current code as the code evolved too much.

If you are still experiencing problems with lock screen showing the desktop, please report a new bug against kscreenlocker product.