Bug 305270

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)?

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?)

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.

Just for the record: I have never experienced this issue so far with radeon. But I also use the plasma-overlay

>  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)

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.

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.

Same here on KDE 4.8.5 (openSUSE 12.2) with the radeon driver.

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.

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.

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

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.

You're describing different bug #313123

Noted, thank you Thomas.

this bug report hasn't seen any comments for almost two years, so I'm wondering whether people are still experiencing the problem?

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.

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.

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.

> 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)

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!

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

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.