Bug 323686

Created attachment 81774 [details]
kwin output while launching and resulting in a black screen

Output of starting kwin. Launch resulted in a black screen and was killed afterwards.

> kwin(11954): Invalid framebuffer status:  "GL_FRAMEBUFFER_UNSUPPORTED" 

this seems to be hit during init of blur effect. Given your GPU output it 
should be supported.

Try to disable the blur effect and maybe check xorg logs whether it contains 
more info.

Given what we see here I think the update to 4.11 is not the root cause, but 
just highlighting a problem somewhere else.

> It is possible to switch to terminal and run "killall kwin".
Suspending the compositor (Shift+Alt+F12) will likely do as well.

> Subsequent launches of KWin most of times return back to black screen.
That's for pretty much sure in the driver then.
Does restarting X11 "fix" it or do you have to reload the kernel module?

* Do you use "vbetool"?
* you could try passing "NVreg_EnableMSI=0" as kernel parameter to the nvidia module (w/o any warranty - you might have to reboot after an STR)

Suspending compositor fixes issue, still at first kwin has to be killed from the terminal to pass screen lock. Subsequent enabling of compositor works fine.

Logging in and out (restart of X11) also works fine.
Restarting X11 or reloading nvidia module doesn't fix the issue.
killall kwin && sleep 10 && kwin also works fine as long as it's run from X session. 
killall kwin && sleep 10 && kwin from the terminal results in black screen. 
--> this could be a driver issue.

It's not connected with blur effect as kwin displays black screen also with all effects disabled. The difference between "normal" and "black" run is presence of following error in kwin output when it fails: kwin(11954) KWin::checkGLError: GL error ( PostPaint ):  "0x506"

vbetool is not in use

"NVreg_EnableMSI=0" doesn't fix the issue. Only difference - mouse cursor isn't visible when kwin is in "black" state.

As it seems to be connected with switching between VT and X11, will report it to nvidia.
Could this bug be related to Bug 322975 ?

Created attachment 82010 [details]
KWin Support Output - NVidia 319.32

I can confirm this bug on my machine with NVidia driver 319.32. Problem started with update to 4.11. Changing OpenGL version in compositing preferences doesn't help.

In the meantime: A quick'n'dirty hack to fix this is to switch compositing by dbus, e. g. in a pm-utils suspend/resume script:
DISPLAY=:0 sudo -u CURRENT_USER qdbus org.kde.kwin.Compositing /Compositor {suspend|resume}

I can confirm this on my laptop as well, have been hunting the solution for ages.  Worked fine on <4.11 and all kernels and all nvidia drivers (304, 310, 319) but now it's sporadic.  Works around 40% of the time.

Yesterday I tried disabling screen lock and setting the screensaver to blank screen, resumed ok this morning but I doubt it's fixed.

(In reply to comment #4)

> all effects disabled. The difference between "normal" and "black" run is
> presence of following error in kwin output when it fails: kwin(11954)
> KWin::checkGLError: GL error ( PostPaint ):  "0x506"

Set tearing prevention to either "none", "only when cheap" or "full scene repaints", then restart kwin - is it still reproducible afterwards?

> Could this bug be related to Bug 322975 ?
Depends on the answer to the above question.
Also if you see this screenshot of the other bug:
http://i.imgur.com/MgB9oKl.png
Does that fit your observation? (Notice that the screen is NOT entirely black - there's sth. like a blurring artifact on the right side)

My issue does not involve Nvidia nor is it a matter from resume.  However, upon any login, I only have my first Desktop available, while the others operate as blank/black backgrounds which I cannot even right click on.

I can run applications on them as well as have my panels there.  No widgets however can be added by right clicking nor to change the background.  The first Desktop is however functional.

A screenshot can be seen here.   I used the Desktop Grid plugin to show you the Desktops in one:  snapshot1.jpg - https://docs.google.com/file/d/0B9TxynTnOrjGTGFsd08tWTA1d0k/edit?usp=sharing .

Remember, Desktops 2-4 (and any more added thereafter) are black but the main panel with the K-menu and clock are operational.  I can open lets say a browser Window.  If I use the Desktop Cube animation to switch to them, yes everything is black so it only looks like a 1-sided cube with Desktop 1 as the only face showing.

My machine is running on an ATI card, KDE 4.11.2 (Kubuntu 13.10).  Should I open a separate bug?  This seem similar.  I have also switched from OpenGL 3.0, 2.1, 1.2 with no fix.  If I turn compositing off with Shift-Alt-F12, the other screens are still blank except for my applications working just fine.

(In reply to comment #8)
> My issue does not involve Nvidia nor is it a matter from resume.  However,
> upon any login, I only have my first Desktop available, while the others
> operate as blank/black backgrounds which I cannot even right click on.
> 
> I can run applications on them as well as have my panels there.  No widgets
> however can be added by right clicking nor to change the background.  The
> first Desktop is however functional.
> 
> A screenshot can be seen here.   I used the Desktop Grid plugin to show you
> the Desktops in one:  snapshot1.jpg -
> https://docs.google.com/file/d/0B9TxynTnOrjGTGFsd08tWTA1d0k/edit?usp=sharing
> .
> 
> Remember, Desktops 2-4 (and any more added thereafter) are black but the
> main panel with the K-menu and clock are operational.  I can open lets say a
> browser Window.  If I use the Desktop Cube animation to switch to them, yes
> everything is black so it only looks like a 1-sided cube with Desktop 1 as
> the only face showing.
> 
> My machine is running on an ATI card, KDE 4.11.2 (Kubuntu 13.10).  Should I
> open a separate bug?  This seem similar.  I have also switched from OpenGL
> 3.0, 2.1, 1.2 with no fix.  If I turn compositing off with Shift-Alt-F12,
> the other screens are still blank except for my applications working just
> fine.

Image here now: https://bugs.kde.org/show_bug.cgi?id=323686

(In reply to comment #8)
> My issue does not involve Nvidia nor is it a matter from resume. 

Completely unrelated.

You either use one activity per virtual desktop and the other activities are not setup with wallpaper and widgets etc. or for some reason the Desktop window lost its assignment to all virtual desktops (some other WMs like ICEWM cause such)

Run konsole and from there "xprop | grep -E '(_NET_WM_DESKTOP|_NET_WM_WINDOW_TYPE_DESKTOP)'" and click the visible deskop.
If it doesn't say:
_NET_WM_DESKTOP(CARDINAL) = 4294967295
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DESKTOP

"something" has screwed the property settings (could be due to plasma-netbook mode)
Check that there's not a rule in place to enforce a specific virtual desktop for the desktop window (run "kcmshell4 kwinrules")

File a bug against plasma/desktop component and elaborate on what could have caused this change.

The screenshots are btw. not accessible anywhere.

(In reply to comment #10)
> (In reply to comment #8)
> > My issue does not involve Nvidia nor is it a matter from resume. 
> 
> Completely unrelated.
> 
> You either use one activity per virtual desktop and the other activities are
> not setup with wallpaper and widgets etc. or for some reason the Desktop
> window lost its assignment to all virtual desktops (some other WMs like
> ICEWM cause such)
> 
> Run konsole and from there "xprop | grep -E
> '(_NET_WM_DESKTOP|_NET_WM_WINDOW_TYPE_DESKTOP)'" and click the visible
> deskop.
> If it doesn't say:
> _NET_WM_DESKTOP(CARDINAL) = 4294967295
> _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DESKTOP
> 
> "something" has screwed the property settings (could be due to
> plasma-netbook mode)
> Check that there's not a rule in place to enforce a specific virtual desktop
> for the desktop window (run "kcmshell4 kwinrules")

Thank you.  You were correct!  Rather than lose my KDE settings, I went to Workspace Behavior > Virtual Desktops.  I set the "Different Widgets for each desktop" on and off.  My desktop was restored.  Do you think I should file this elsewhere as a resolved bug, or move on?  It was after an upgrade to Kubuntu 13.10.

I fear there's little to hook on, esp. if you didn't chek the mentioned properties.

I assume that the properties were set in a way that the desktop window was not on all virtual desktops, but *why* this happened is hard to say.

KWin would set a desktop type window that is on no particular desktop on all desktops, so the important question would be whether the window was not desktop typed or set on a particular (rather than on all or none) desktop.

If it happens again, dump the entire "xprop" output of the visible desktop window and file a bug against the desktop containment component of plasma.

Thanks Thomas.   I did check the properties and as you said they were not
correct.   It may have been helpful to trustee the output but it appears it
was just not helpful since the extra Desktops had nothing set.   Only the
first one did as you related.  I realized that resetting the widgets did
rewrite  settings about the Desktop window properties to as they should be.

Since this had nothing to do with this bug, I appreciate your help by
setting me in the right direction to solve it and will end my issue here.

I have the same problem since 4.11, for some time disabling and enabling back Desktop effects with Alt+shift+F12 was doing the trick, but lately even this isn't working anymore. By the way "pm-suspend" and "systemctl suspend" work as intended, no black screen on resume. Black screen happens only when suspending through kde menu.

(In reply to comment #14)
> By the way "pm-suspend" and "systemctl suspend" work as intended
Do you call those from the X11 VT or from VT1?

This would sound crazy, but after update just 15 min ago everything start working, I chacked 3 times!!! "upower" was updated, maybe thats the reson.

(In reply to comment #16)
> This would sound crazy, but after update just 15 min ago everything start
> working, I chacked 3 times!!! "upower" was updated, maybe thats the reson.

No updates to kerne/nvidia driver (*is* nvidia driver?)
Which versions of upower/kernel/nvidia do you run now?

(In reply to comment #17)
> (In reply to comment #16)
> > This would sound crazy, but after update just 15 min ago everything start
> > working, I chacked 3 times!!! "upower" was updated, maybe thats the reson.
> 
> No updates to kerne/nvidia driver (*is* nvidia driver?)
> Which versions of upower/kernel/nvidia do you run now?

Linux 3.11.6-1
upower 0.9.23-2
nvidia 325.15-10

I am tired of fighting with "suspend to ram". Now I discover that GPU is at performanse level 3 all the time after resume, so it is heating, fan starts making noise, have no idea what is causing this, never had that before.

I've been trying things the last few weeks to try and narrow it down and here are my observations.  Doesn't seem to be kernel or nvidia related as I have experimented with this, as soon as kde is updated to 4.11, that's when it seems to start.  Now, I have noticed, and I recall reading about this somewhere before, if I suspend whilst the ac adapter is plugged in, then resume after unplugging it, it resumes most of the time.  Here are some other observations about successful resumes:

1. AC adaptor plugged in, suspend, unplug AC adaptor, resumes fine most of the time, say 85%.
2. AC adaptor unplugged, suspend, resume, works most of the time.
3. AC adaptor plugged in, suspend, resume, works around 40% of the time.
4. AC adaptor plugged in, suspend, AC adaptor unplugged, resume, works 40% of the time.

I don't know if any of the above helps and it's only observations, suspend logs seem to be mostly ok.  Have also tried switching off wifi before a suspend but this appears to hav no effect.  Also, I haven't noticed any particular difference using pm-suspend, laptop function and sleep key or systemd suspend.

To fix it when it resumes to garbled graphics or black screen, I blindly press 'alt and F2' to get krunner and type 'kwin --replace'.  This fixes it perfectly.  Obviously I'd prefer it did it automatically again.

I can supply logs if you tell me which ones to supply and under what conditions.


Myrmidon

I should add that I'm using Linux Mint 13 with kubuntu backports enabled,
3.10.9 kernel
Nvidia 319.32

I don see any system either. I've experienced couple black screens after switching between virtual terminals (only mouse pointer visible as usual). Also seems like after killing X with ctrl-alt-back and restarting X,  kde suspends and resumes without problem. Also this strange high gpu (only gpu, cpu near zero) loads after resuming sometimes. Recent update of upower package definitely changed the behaviour of suspend function. And yes, it all started with 4.11. Maybe some big changes of power management system are going on? Until the next release of kde, "systemctl suspend" or "pm-suspend" should do fine.

At least for linux 3.11 on 32bit there's a known issue (which i believe to cause my current inability to resume from STR at all)
https://bugzilla.kernel.org/show_bug.cgi?id=61781

No idea whether that affected 3.10.9 (resp. ubuntu eventually backported kernel stuff)

It's rather unlikely that the way to trigger the suspense has actual impact on it (also see comment #19 in this regard).

Another thing is that compositing apparently has no (direct) impact on this (comment #14 - and does not have for me. Not even switching to VT1, isolating multiuser target and unloading the nvidia driver has...)

I got the update Cobalt spoke of with the upower update, this has had no effect.  Also, when I regress to previous kernels, the same behaviour occurs which still makes me think it's kde 4.11 related.

(In reply to comment #23)
> which still makes me think it's kde 4.11 related.

Question is: "How"?

You say it's not depending on how STR is triggered, compositing (thus GL on the GPU) is out of the game as well...


The only things left i could suggest would be to shutdown either

- kcmshell4 kded # shutdown various services, starting by PowerManagement
- kquitapp plasma-desktop # desktop gone
- kquitapp krunner # alt+f2 runner gone
- kquitapp kwin # WARNING you've no more any reasonable focus input management!

before suspending and see whether any has any reproducible impact.

Ok, I found the bug report I saw ages back with a similar problem here:

https://bugs.kde.org/show_bug.cgi?id=205803

This is exactly my issue.  If I suspend with AC adaptor attached then resume with no AC adaptor attached, it resumes perfectly EVERY time.  I tried this quite a few times last night.  Any other combination gives garbled graphics, back screen with mouse pointer or in the odd occasion resumes ok.

That previous bug suggests it was an xorg server issue, maybe that's something I should look at.  I see I am on xorg 1.7.6+12ubuntu2 and xserver-xorg-core 2:1.12.3+git20120709.

Can anyone else confirm this?

I had the same issues as described in this bug (black screen with errors - had to kill kdm - pm-suspend did work however) and it's finally solved by today's system upgrade. upower was among the upgraded packages (0.9.22-1 -> 0.9.23-2).

Additional note to my comment (#26): I made a downgrade of upower to check if the problem comes back, but it didn't. Here's a list of packages I updated today (removed a couple of obvious ones from the list like firefox and thunderbird):

 [PACMAN] upgraded archlinux-keyring (20130926-1 -> 20131027-1)
 [PACMAN] upgraded argyllcms (1.6.0-1 -> 1.6.1-1)
 [PACMAN] upgraded arpack (3.1.2-1 -> 3.1.2-2)
 [PACMAN] upgraded audit (2.3.2-1 -> 2.3.2-2)
 [PACMAN] upgraded tzdata (2013g-1 -> 2013h-1)
 [PACMAN] upgraded glibc (2.18-8 -> 2.18-9)
 [PACMAN] upgraded cracklib (2.9.0-1 -> 2.9.0-2)
 [PACMAN] upgraded db (5.3.21-2 -> 5.3.28-1)
 [PACMAN] upgraded libgssglue (0.4-1 -> 0.4-2)
 [PACMAN] upgraded libtirpc (0.2.3-1 -> 0.2.3-2)
 [PACMAN] upgraded pam (1.1.8-1 -> 1.1.8-2)
 [PACMAN] upgraded libcups (1.6.4-1 -> 1.7.0-1)
 [PACMAN] upgraded cups-filters (1.0.40-1 -> 1.0.41-1)
 [PACMAN] upgraded cups (1.6.4-1 -> 1.7.0-1)
 [PACMAN] upgraded device-mapper (2.02.103-1 -> 2.02.103-2)
 [PACMAN] upgraded python2-numpy (1.7.1-2 -> 1.7.1-3)
 [PACMAN] upgraded dispcalgui (1.2.7.0-2 -> 1.5.3.1-1)
 [PACMAN] upgraded dotconf (1.3-3 -> 1.3-4)
 [PACMAN] upgraded libpulse (4.0-2 -> 4.0-6)
 [PACMAN] upgraded ffmpeg (1:2.0.2-3 -> 1:2.1-1)
 [PACMAN] upgraded ffmpeg-compat (1:0.10.8-5 -> 1:0.10.9-1)
 [PACMAN] upgraded sqlite (3.8.1-1 -> 3.8.1-2)
 [PACMAN] upgraded fltk (1.3.2-3 -> 1.3.2-4)
 [PACMAN] upgraded gawk (4.1.0-1 -> 4.1.0-2)
 [PACMAN] upgraded gdbm (1.10-2 -> 1.10-3)
 [PACMAN] upgraded gettext (0.18.3.1-1 -> 0.18.3.1-2)
 [PACMAN] upgraded git (1.8.4.1-1 -> 1.8.4.2-1)
 [PACMAN] upgraded gpm (1.20.7-3 -> 1.20.7-4)
 [PACMAN] upgraded grep (2.14-2 -> 2.15-1)
 [PACMAN] upgraded hugin (2012.0.0-8 -> 2013.0.0-2)
 [PACMAN] upgraded pciutils (3.2.0-3 -> 3.2.0-4)
 [PACMAN] upgraded hwloc (1.7.1-1 -> 1.7.2-1)
 [PACMAN] upgraded lib32-glib2 (2.38.0-1 -> 2.38.1-1)
 [PACMAN] upgraded lib32-libpng (1.6.5-1 -> 1.6.6-1)
 [PACMAN] upgraded lib32-libcups (1.6.4-1 -> 1.7.0-1)
 [PACMAN] upgraded lib32-util-linux (2.23.2-1 -> 2.24-1)
 [PACMAN] upgraded libdvdcss (1.2.13-2 -> 1.2.13-3)
 [PACMAN] upgraded libglade (2.6.4-4 -> 2.6.4-5)
 [PACMAN] upgraded libieee1284 (0.2.11-4 -> 0.2.11-5)
 [PACMAN] upgraded libmatroska (1.4.0-2 -> 1.4.1-1)
 [PACMAN] upgraded libmediainfo (0.7.63-1 -> 0.7.64-1)
 [PACMAN] upgraded libofa (0.9.3-4 -> 0.9.3-5)
 [PACMAN] upgraded libsrtp (15.1c9bd90-1 -> 15.1c9bd90-2)
 [PACMAN] upgraded linux-firmware (20130903-1 -> 20131013.7d0c7a8-1)
 [PACMAN] upgraded lvm2 (2.02.103-1 -> 2.02.103-2)
 [PACMAN] upgraded lzo2 (2.06-1 -> 2.06-3)
 [PACMAN] upgraded mediainfo (0.7.63-1 -> 0.7.64-1)
 [PACMAN] upgraded nspr (4.10.1-1 -> 4.10.1-2)
 [PACMAN] upgraded ppl (1.0-1 -> 1.1-1)
 [PACMAN] upgraded sane (1.0.24-2 -> 1.0.24-3)
 [PACMAN] upgraded texlive-bin (2013.30973-5 -> 2013.30973-6)
 [PACMAN] upgraded upower (0.9.22-1 -> 0.9.23-2)
 [PACMAN] upgraded virtualbox (4.3.0-2 -> 4.3.0-3)
 [PACMAN] upgraded vlc (2.1.0-4 -> 2.1.0-5)
 [PACMAN] upgraded wavpack (4.70.0-1 -> 4.70.0-2)
 [PACMAN] upgraded wine (1.7.5-1 -> 1.7.5-2)
 [PACMAN] upgraded xorg-xinit (1.3.3-1 -> 1.3.3-2)

Which one might be the cause?

 [PACMAN] upgraded hwloc (1.7.1-1 -> 1.7.2-1)
 [PACMAN] upgraded lib32-util-linux (2.23.2-1 -> 2.24-1)
 [PACMAN] upgraded linux-firmware (20130903-1 -> 20131013.7d0c7a8-1)
best candidates besides upower.
might be a completely different device then. do you use the nvidia blob at all?

 [PACMAN] upgraded upower (0.9.22-1 -> 0.9.23-2)
well, best actually candidate ... but you say it's not.

--

The other pot. suspects are just upgpkg... it's really unlikely they're the cause.

 [PACMAN] upgraded glibc (2.18-8 -> 2.18-9)
a bug in glibc is unlikely but had severe impact all over the  system 
 [PACMAN] upgraded pam (1.1.8-1 -> 1.1.8-2)
 [PACMAN] upgraded device-mapper (2.02.103-1 -> 2.02.103-2)
 [PACMAN] upgraded pciutils (3.2.0-3 -> 3.2.0-4)
 [PACMAN] upgraded libglade (2.6.4-4 -> 2.6.4-5)
running xscreensaver?
 [PACMAN] upgraded lvm2 (2.02.103-1 -> 2.02.103-2)
in use?
 [PACMAN] upgraded xorg-xinit (1.3.3-1 -> 1.3.3-2)
(and not if you launch via kdm anyway)

Ultimately of course
 [PACMAN] upgraded libpulse (4.0-2 -> 4.0-6)
because lennart is *always* a good choice for blaming ;-)

I wonder if you have something I do not package wise, I'm on an ubuntu derivative so maybe some packages are different as the upower upgrade did not fix this for me.

A quick check shows I don't have 2 out of the 3 other candidates installed.  I don't have 'hwloc' installed and lib32-util-linux doesn't seem to show up on synaptic at all.

I still have black screen after all updates, but I found solution without killing X-session.
"kwin --replace" in another virtual terminal resumes normal functionality.

Ah yes, I forgot, and "export DISPLAY=:0" before that. 

(In reply to comment #30)
> I still have black screen after all updates, but I found solution without
> killing X-session.
> "kwin --replace" in another virtual terminal resumes normal functionality.

(In reply to comment #30)
> "kwin --replace" in another virtual terminal resumes normal functionality.

Try just restarting the compositor (Shift+Alt+F12)
I recently got (after updating the nvidia driver) occasional black windows (but NOT decorations) when calling kwin to reconfigure, but it got less with nvidia 325.15 again.

I know, I used Shift+Alt+F12 for quite some time and this problem was tolerable with it, but week ago or so after upgrade of upower or something else this trick with restart of desktop effects doesn't work anymore, so I needed to kill X, which is unacceptable. So "kwin --replace" is the only quick fix for me now.

(In reply to comment #32)
> (In reply to comment #30)
> > "kwin --replace" in another virtual terminal resumes normal functionality.
> 
> Try just restarting the compositor (Shift+Alt+F12)
> I recently got (after updating the nvidia driver) occasional black windows
> (but NOT decorations) when calling kwin to reconfigure, but it got less with
> nvidia 325.15 again.

'kwin --replace' is the only thing working for me just now also.  My earlier thought of AC adaptor plugged, suspend, unplug then resume doesn't fix it after all.

I've to redraw comments #26 and #27, the problem is not solved yet, but somehow happens more sporadic. It came back yesterday and neither "kwin --replace" nor "Shift+Alt+F12" helps. I made an additional system upgrade, so maybe one of the packages broke it again, but I'm not sure.

This is very frustrating!  I switched of screenlock and it resumed fine 4 times in a row, then just when I was about to have some hope, the next resume was garbled as usual. :(  Is there someway that the kde profile could have been corrupted with upgrades?  I have seen some people talking about changing some .folders like .kde etc.  Is this perhaps related at all?

This bug has become a mess - different ppl. with different experiences and the only common thing is that resume from STR does not work.

So forgive me that i've to ask back, but is KWin compositing active while you suspend to ram (and resume) or not?
If it is, does the problem remain for you if you suspend the compositor (Shif+Alt+F12) before suspending?
If not, check the Compositor backend in "kcmshell4 kwincompositing", 3rd tab.
-> Does it happen with XRender compositing?
-> Does it happen with any GL mode?
-> Does it happen with any tearing prevention?


FTR:
(Esp. when unrelated to KWin compositing,) I remain convinced that these are indeed two issues and that they are in the kernel or the nvidia blob, because i've been running what is now 4.11 for ~5 month and only few weeks ago the nvidia blob started to show invalid ("black") textures when reconfiguring KWin and after (pretty delayed compared to package availability) updating to kernel 3.11.x I simply cannot resume from STR anymore at all - no matter wheter X11 is running or even the nvidia driver is loaded - AND there's a known bug in the 3.11 kernel.

I'll report back when arch ships 3.12.0 (what should no last too long anymore =) and I hopefully can STR again.

Ok, switching off compositing before suspend is looking promising so far, 6 successful resumes in a row.  How and where would I add this in a script, would comment 5 be the way to do it?

(In reply to comment #38)
> Ok, switching off compositing before suspend is looking promising so far, 6
> successful resumes in a row.  How and where would I add this in a script,
> would comment 5 be the way to do it?

Quick'n'Dirty (temporary) fix - works great for me since September:

* Get the script suspend_kde_compositing.sh from attachments
* at least change YOURUSERNAME to your usual X username or install xuserrun
* save it as root and mark it executable
* move it to...
    /etc/pm/sleep.d/ (if you still use old init system)
    or
    /usr/lib/systemd/system-sleep/ (if you use systemd)

this should work out of the box for most users.

BTW: I get the same strange black-screen-bug when switching to and back from framebuffer console!

Created attachment 83382 [details]
Temporary fix

Hi Stefan,

I tried your fix and it didn't work on the first pass.  Should I have my user name written as 'user' or '$user'?  If I have it correct then maybe the screenlocker is getting in the way somehow?

New observation, alt+shift+f12 also works instead of 'kwin --replace'.

Forget that, for some reason when I was editing I forgot to change it to executable, doh!

Script is looking to be working good Stefan!  :D  I'll keep you updated.

Just came to my mind: you're not using the nvidia blob alongside a framebuffer console, are you?

dmesg would contain sth. like "NVRM: requires the use of a text-mode VGA console"

--
no: i still cannot resume. really no idea what module blocks :-(

(In reply to comment #44)
> Just came to my mind: you're not using the nvidia blob alongside a
> framebuffer console, are you?

Yes, I am and disabling the framebuffer seems to solve the problem.

Ok, that was too fast, it happened again.
But it seems to have gotten less. Well more testing would be necessary ...

Using compiz instead of kwin also fixes the problem

Same bug in my system after upgrade to KDE 4.11
Gentoo x86 (stable tree) : reproducible at all kernels I have

Still using old init system (too lazy to migrate =)
The Temporary fix works for me fine.

I also have a black screen after resume from suspend problem similar to this and can always fix the problem with Shift+Alt+F12, but normally I only get the problem when I have more than the usual number of windows open (normal for me is over 100 knotes, over 30 browser tabs, multiple terminal windows, email, chat, and some editor windows), such as when I'm doing programming and open IDEs and programming documents.  I also have to disable compositing while playing some games for all of the game textures to render.  Using OpenGL 2.0 Compositing type with Raster Qt graphics on KDE 4.11.5, nvidia drivers 331.38, Gentoo x86_64, GeForce GTX 560M (GF116) with 3072MB of virtual graphics memory.  TripleBuffer is also set to true in xorg.conf.

Any news on this? I'm also affected by this bug and it's driving me crazy.
What I observed so far:
1.) If I suspend compositing before STR and resume it on suspend via a script, it allways works BUT: Sometimes the 'Blur' effect is not working any more. Issuing a kwin --replace resumes normal functionality.
2.) I can trigger this issue only with KDE, I tried another DE (Gnome,Xfce), but could not reproduce it, so this is actually a KDE fault? I don't know.
3.) I can also trigger the issue when switching to VT and back to X sometimes. Maybe this is a chance to debug the problem?

@Thomas:
Do you think it is possible to somehow gdb'ing into kwin from another tty, and find out what is going on? Or is there a better way? If so, I would try this as soon as i have some time, if you can give me some hints;)
I also have a question regarding tearing prevention in kwin, maybe it is also related to this problem:
Would it have any effect to set __GL_YIELD="USLEEP" or unset the TRIBLE_BUFFER option is xorg.conf. Which combination is recommended for the nvidia blob? Unfortunately, i don't understand why i need triple buffering because as far as i know using the GLX_EXT_buffer_age extension should be sufficient for Tearing Prevention, isn't it? Just interested.

FTR: since kernel 3.14, i can STR again - yeah =)
I do however not (never) run into a black screen right now.

(In reply to comment #50)

> 1.) If I suspend compositing before STR and resume it on suspend via a
> script, it allways works BUT: Sometimes the 'Blur' effect is not working any
> more. Issuing a kwin --replace resumes normal functionality.
> 2.) I can trigger this issue only with KDE, I tried another DE (Gnome,Xfce),
> but could not reproduce it, so this is actually a KDE fault? I don't know.

Can you trigger it w/o the blur effect? ("kcmshell4 kwincompositing", 2nd tab)

> 3.) I can also trigger the issue when switching to VT and back to X
> sometimes. Maybe this is a chance to debug the problem?

Are you using the nvidia blob alongside a framebuffer console?
dmesg would contain sth. like "NVRM: requires the use of a text-mode VGA console"
(see comment #44 ff.)

> 
> @Thomas:
> Do you think it is possible to somehow gdb'ing into kwin from another tty,
> and find out what is going on?
You can gdb into kwin from VT1 or via ssh - just not from the X11 server (since the halted code would prevent updates in the compositor)

   gdb --pid `pidof kwin`

If you run into permission trouble, run
 echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

> I also have a question regarding tearing prevention in kwin, maybe it is
> also related to this problem:
No. (Or rather: "unlikely")

> Would it have any effect to set __GL_YIELD="USLEEP" or unset the
> TRIBLE_BUFFER option is xorg.conf.

It's: Option  "TripleBuffer"                  "True"
Neither is actually related to V'Sync, just w/o the nvidia driver performs busy waits on buffer swapping.
We have a bug report that says kwin (the nvidia driver) uses 100% when switching to VT1 and TripleBuffer is NOT enabled.

> Which combination is recommended for the nvidia blob?
Primary desktop usage? TripleBuffer'ing.
The argument against is the 1 frame delay what some hardcore gamers see as a problem.
The bonus is better performance and no risk of busy waits.

> Unfortunately, i don't understand why i need triple buffering
> because as far as i know using the GLX_EXT_buffer_age extension should be
> sufficient for Tearing Prevention, isn't it?
No. GLX_EXT_buffer_age allows to only have to update a fraction of the scene. Swapping buffers is still required to change the scanout buffer during the vertical "rescan" time (so that you cannot see it)
W/o triple buffering, this *aligned* swap would block (waiting for the next rescan)
TripleBuffering pushes the waiting buffer into a third (! ;-) buffer and allows the user code to start updating the backbuffer immediately.

Hi Thomas,

many thanks for your patience to answer all my questions, especially regarding tearing prevention. I will configure my xorg.conf to use Triple Buffering. If I understood you right, I don't need the __GL_YIELD="USLEEP" environment setting in addition to that?

As for debugging the "Black Screen" problem, first, I'm glad to hear that you can't reproduce the problem with kernel 3.14 anymore. I'm currently on the move and have no access to my machine. As soon as I'm back I will upgrade the kernel and cross my fingers that it will work. 

Regarding your questions:
I'm using the nvidia blob with the EFI framebuffer because I'm booting in UEFI mode with CSM disabled, so this is the only way to get any output on the VTs. I also tried with legacy BIOS boot and without FRAMEBUFFER driver (only VGA console as demanded by NVIDIA), but that didn't help either, black screen was still there plus I was loosing the output on the VTs after some resume cycles.

Anyway, I will try to update the kernel/nvidia drivers and kwin to the latest stable version. If the problem still occurs, I will get my hands dirty and try to debug kwin;)
Thanks again for your tips regarding that, will post again if I have some results.

(In reply to comment #52)
> I don't need the __GL_YIELD="USLEEP" environment setting in addition to that?
No, it's just to prevent busy waiting on double buffering but is not required for triple buffering.

> As for debugging the "Black Screen" problem, first, I'm glad to hear that
> you can't reproduce the problem with kernel 3.14 anymore.
That's a misunderstanding. I have *never* faced *this* bug, but on some kernels could not resume from STR at all (kernel hung, no echo on ping, box dead)

> I'm using the nvidia blob with the EFI framebuffer because I'm booting in
> UEFI 
This has nothing to do with EFI/UEFI or BIOS, but is related to the linux terminal graphics modes.
This can be configured for grub, see eg. here:
https://wiki.archlinux.org/index.php/GRUB#Disable_framebuffer

Ok, i have upgraded the kernel to 3.14.3 and kwin to 4.11.9 and I can no longer
reproduce the problem with the black screen. So far, I have tested more than 10 STR
cycles in a row but never faced the issue.

(In reply to comment #53)
>That's a misunderstanding. I have *never* faced *this* bug, but on some kernels could not >resume from STR at all (kernel hung, no echo on ping, box dead)
Sorry for the misunderstanding.

>This has nothing to do with EFI/UEFI or BIOS, but is related to the linux terminal graphics >modes.
Maybe I was a little bit unclear. It is related to booting the kernel in EFI mode. Setting that parameter in the GRUB config simply has no effect when booting the kernel in EFI mode, since
then the standard VGA text console is not available for the terminal graphics (VTs). As far as i understood, in EFI mode, the only kernel "driver" for terminal graphics is either the EFI framebuffer driver or the native in-kernel card driver(KMS console).
The mentioned GRUB configuration forces the kernel to use the standard VGA text console driver
for terminal graphics, after grub has passed control to the kernel. But this is not available when booting in EFI mode.

Happens on my machine on kernel 3.13.24, and on kernel 3.15.5 using nvidia blob. To reproduce consistently the following steps must be taken

1. Open an application and display the application full screen. ( I tested with firefox and with gwenview).
2. Minimize the application.
3. Suspend and resume. (Get black screen with cursor on resume) ...or same behavior switching to a tty VT and then back to the graphics VT

If you then restart the compositor (alt-shift-F12 x2 ), even if you restore the application to some other display state other than minimized (or full screen), the behavior(black screen) on resume will continue as long as that application is open.  Closing the application will fix the problem. That is, if you kill the application, you will then be able to resume from suspend normally

(In reply to Stuart Citrin from comment #55)
> Happens on my machine on kernel 3.13.24, and on kernel 3.15.5 using nvidia
> blob. To reproduce consistently the following steps must be taken
> 
> 1. Open an application and display the application full screen.
What's the output of:
   qdbus org.kde.kwin /KWin supportInformation | grep unredirectFullscreen


> 2. Minimize the application.
What's the output of:
   qdbus org.kde.kwin /KWin supportInformation | grep hiddenPreviews

> behavior switching to a tty VT and then back to the graphics VT
What's the output of:
   dmesg | grep NVRM

(In reply to Thomas Lübking from comment #56)

> > 1. Open an application and display the application full screen.
> What's the output of:
>    qdbus org.kde.kwin /KWin supportInformation | grep unredirectFullscreen
unredirectFullscreen: false
> 
> 
> > 2. Minimize the application.
> What's the output of:
>    qdbus org.kde.kwin /KWin supportInformation | grep hiddenPreviews
> 
hiddenPreviews: 0
> > behavior switching to a tty VT and then back to the graphics VT
> What's the output of:
>    dmesg | grep NVRM
   16.758745] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  304.117  Tue Nov 26 21:25:36 PST 2013


Please note the following:

The culprit appears to be with the 'Magic Lamp' effect.  The full screen stuff is probably irrelevant.  If you minimize (or restore) with  'Magic Lamp' enabled, then the next time you leave and return to graphics you get the black screen.  If kwin is restarted and 'Magic Lamp' is  not enabled, minimize something,  then returning to the graphics VT will properly render. I tested this about 20 times and it is totally consistent.

But also note (here's where it gets annoying):

I recently switched from Archlinux (with a KDE desktop) to Mint KDE. I would upgrade Arch every two weeks fairly consistent over the past three years and never saw the behavior occur. It only occurs when running Mint KDE. (same physical machine/hardware). 

(I will see if I can get a more recent Nvidia driver to work with the card which is an 8500GT and see if same result).

Can now reproduce on Archlinux also:
linux 3.15.5
nvidia 340.24
kdebase-workspace 4.11.10  (which is latest available on ARCH )

I've to confirm that disabling magic lamp seems to workaround the issue.

Magiclamp indeed seems the trigger.
This seems to affect (all, including the desktop) window textures, but not eg. the textures from BE::Clock and i can also still see the window labels when entering present windows mode.
Also a suspend/resume of compositing sanitizes the scene.

Starting xbmc on the archlinux for the first time (second time is ok) after reboot or resume also triggers "black screen" sometimes with some remains of the deformed images of desktop. Quitting xbmc and restarting the compositor (Shift+Alt+F12) helps.

This bug is most likely duplicate of the bug 322975

Turning the Magic Lamp effect off solved my resume from suspend problem too!

*** Bug 339030 has been marked as a duplicate of this bug. ***

I am unable to get Stefan Werner's patch  (attachment 83382 [details]) named suspend_kde_compositing.sh to work as a systemd script in /usr/lib/systemd/system-sleep. I tested it by commenting out the resume stanza which should then cause compositing to be turned off upon resume.  However, it always resumes with compositing still on so it did not suspend compositing.  So, I ran the following script as root in Konsole:

DISPLAY=:0 sudo -u gordon qdbus org.kde.kwin.Compositing /Compositor suspend

I then get the following error:

Could not connect to D-Bus server: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11

Am I doing something wrong? Any ideas or recommendations?

Thanks,

Gordon

You need to find the dbus session address somehow.
then use it with something like:

sudo -u $user sh -c "DBUS_SESSION_BUS_ADDRESS=\"$dbus\" DISPLAY=\"$dply\" Command here"

Check this archlinux aur package (is for gnome, so replace gconf-helper with something kde related like "plasma-desktop"
https://aur.archlinux.org/packages/ba/batterylife/batterylife.tar.gz

...of course a proper fix upstream would be better

PID=`pidof kwin`
export `tr '\0' '\n' < /proc/${PID}/environ | grep DBUS_SESSION_BUS_ADDRESS`

"fix" is required in nvidia blob - at best we can figure what triggers this and avoid that in the effect (if possible while preserving the effect itself)

I've never seen a black screen with Magic Lamp but, with or without this effect, it's about 5 months that I see weird things on resuming from suspend randomly, from blurred fonts to a displacement of the whole screen to the right. Sometimes, after resuming from hibernation, the background of Conky is messed up too. A simple log-out/log-in has always worked for me.

I think this isn't a bug in KDE but in nVidia. Gnome users are afflicted too (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768896). nVidia devs admit a bug that may be the cause (https://devtalk.nvidia.com/default/topic/787748/linux/-nvidia340xx-archlinux64-gnome3-14-the-background-of-desktop-and-lockscreen-mess-after-resume-from-/). And, if I correctly remember, I once saw screen displacement under Enlightenment and after resumimg from suspend.

Suspension of KDE compositing before suspend/hibernation and resuming it after wake-up with a systemd script work for me.

Bad news: Today I saw blurred fonts after resuming from suspend, even with the above-mentioned systemd script! Logging out and in fixed it as always; restarting KDE compositing didn't. That can mean that nVidia's problem isn't specific to compositing.

I have a similar issue with ATI graphics card , open-source driver.  Sometimes after returning from a screen-off (screensaver switches off monitor due to inactivity) the whole desktop is blurry.  Switching to a console terminal and back (ctrl-alt-f2, ctrl-alt-f7) fixes the issue.

> (In reply to Radics Péter from comment #71)
> I have a similar issue with ATI graphics card , open-source driver. 
> Sometimes after returning from a screen-off (screensaver switches off
> monitor due to inactivity) the whole desktop is blurry.  Switching to a
> console terminal and back (ctrl-alt-f2, ctrl-alt-f7) fixes the issue.

The issue discussed here is about resuming from suspend.

Maybe.
The original bug mentions "login" what implies not only STR, but also screenlocking.

-> Does anybody get this on plain resume from STR (ie. NO screenlocker/saver before or after the suspend)?

I don't use screenlocker/saver and I don't get a black screen (with magic lamp) but I get other weird effects after resume (Comment #69). The systemd script has worked for me with just one exception (Comment #70).

I have same effect of garbled and/or black screen after resuming from sleep, switching between terminal and starting xbmc in fullscreen mode for the first time (secong time is ok). Fixing it by suspending and turning back the compositor (Shift+Alt+F12).

*** This bug has been marked as a duplicate of bug 344326 ***

This bug is NOT a duplicate of bug 344326 and should therefore not be marked as such.  See comments 5 and 6 in bug 344326 by Ruslan and Alexander.

I just wanted to add that I don't see any of these issues in my laptop whose primary graphics card is Intel; another evidence that they could be attributed to nVidia, not KDE.

What does the intel system print for:

glxinfo| grep -E '(GL_ARB_draw_elements_base_vertex|GL_ARB_copy_buffer|GL_ARB_map_buffer_range)'

(In reply to Thomas Lübking from comment #79)
> What does the intel system print for:
> 
> glxinfo| grep -E
> '(GL_ARB_draw_elements_base_vertex|GL_ARB_copy_buffer|GL_ARB_map_buffer_range
> )'

GL_ARB_copy_buffer, GL_ARB_copy_image, GL_ARB_debug_output, 
GL_ARB_draw_elements_base_vertex, GL_ARB_draw_instanced, 
GL_ARB_map_buffer_alignment, GL_ARB_map_buffer_range, GL_ARB_multi_bind, 
GL_ARB_copy_buffer, GL_ARB_copy_image, GL_ARB_debug_output, 
GL_ARB_draw_elements_base_vertex, GL_ARB_draw_instanced, 
GL_ARB_map_buffer_alignment, GL_ARB_map_buffer_range, GL_ARB_multi_bind,

And if helpful,  this is the output of:

optirun glxinfo| grep -E '(GL_ARB_draw_elements_base_vertex|GL_ARB_copy_buffer|GL_ARB_map_buffer_range)'

GL_ARB_conservative_depth, GL_ARB_copy_buffer, GL_ARB_copy_image,
GL_ARB_draw_elements_base_vertex, GL_ARB_draw_indirect,
GL_ARB_map_buffer_range, GL_ARB_multi_bind, GL_ARB_multi_draw_indirect,
GL_ARB_copy_buffer, GL_ARB_copy_image, GL_ARB_debug_output,
GL_ARB_draw_elements_base_vertex, GL_ARB_draw_indirect,
GL_ARB_map_buffer_range, GL_ARB_multi_bind, GL_ARB_multi_draw_indirect,

Created attachment 93292 [details]
Distorted screen on resume from suspend

I have a strange distorted screen too, on resume from suspend. (See attached file)

What I tried so far:
- Disabling Magic Lamb (Does not help)
- Setting KWIN_USE_BUFFER_AGE to 0 (Does not help either)
- Creating two scripts, one for /etc/acpi/suspend.d and one for /etc/acpi/resume.d to disable/enable the compositor (Works partly)
- Disabling the compositor all together (Sure this works, but I would miss the animation)

-------- compositor-off.sh
#!/bin/sh
export DISPLAY=:0
if $(qdbus org.kde.kwin /KWin compositingActive)
then
    qdbus org.kde.kwin /KWin toggleCompositing
fi
-------- compositor-on.sh
#!/bin/sh
export DISPLAY=:0
if ! $(qdbus org.kde.kwin /KWin compositingActive)
then
    qdbus org.kde.kwin /KWin toggleCompositing
fi

In short, I couldn't manage to work around this problem nor does any other suggestion help, I found on the web. However, I have recognized, when setting the Animation speed to 'Instant' this strange effect does happen rarely. When setting the Animation speed to 'Very slow' the strange effect happens every time regardless of the two scripts or any other suggestion.

But needless to say when setting the animation speed to 'Instant' yout can turn it off all together as you wouldn't really recognize an effect anyway.

Also this effect happens when adjusting my monitors in the 'Display Configuration' panel. For instance moving one screen up or down and pressing apply (Adjusting the Animation speed does not prevent it from happening). I used this reproducible bug to create the attached image.

Unfortunately, this bug is still present in KDE 5. (I use Fedora 22 KDE spin)

(In reply to Christux from comment #82)
This interface:

> if $(qdbus org.kde.kwin /KWin compositingActive)
> then
>     qdbus org.kde.kwin /KWin toggleCompositing
> fi

is gone in KWin 5 - use
qdbus org.kde.KWin /Compositor suspend
and
qdbus org.kde.KWin /Compositor resume

> Unfortunately, this bug is still present in KDE 5. (I use Fedora 22 KDE spin)
Assuming this is on nvidia (ie. "this bug") there's a chance for a workaround in 5.4 (KWin, NOT KF5 which is already at 5.11 or so):
https://bugs.kde.org/show_bug.cgi?id=344326#c53

The bug itself is -probably, it sorted out- in the nvidia driver and a problem when vertex buffer object are copied between system and video RAM.

I don't know. Ever since I've disabled the Magic Lamp, I've never had this problem anymore. I wonder why it doesn't work mor some.

    $ uname -roms && kwin_x11 --version
    Linux 4.0.5-1-ARCH x86_64 GNU/Linux
    kwin 5.3.1

(In reply to marcodv from comment #84)
> I don't know. Ever since I've disabled the Magic Lamp, I've never had this
> problem anymore. I wonder why it doesn't work mor some.

The magic lamp effect drastically increases the amount of quads used to build the window - what simply raises the odds to hit bad memory.
You'll figure with 5.4 (feel brave to re-enable the magic lamp effect then)

Thanks for the update about the gone interface, and for the link.

I still have an 'older' kwin version.

$ kwin --version
5.3.1

So I need to wait a bit until it is available through the fedora updates
repository or kde-unstable/kde-testing repository.
Can't wait to test this :-). If it is not in the repo until 01.07 I will build
it my self.

I put now:

qdbus org.kde.KWin /Compositor suspend

into /etc/acpi/suspend.d/composite-off.sh and

qdbus org.kde.KWin /Compositor resume

into /etc/acpi/resume.d/composite-on.sh


*Note*:
When I suspend my session and take out my laptop from the docking station
(Lenovo T520) and resume from suspend the screen is distorted too, even though
it wouldn't be the case when resuming from suspend with to laptop docked. It
looks like kwin still thinks that both screens are connected. The only thing
which helps in this situation is either killing the xserver or putting the
laptop back, locking blindly into the session, calling 'kwin --replace', 
killing
and restarting plasmashell and last but not least restarting kded5 wouldn't 
hurt
either. In short it is mess. But lets see, maybe in 5.4 this will be gone
too. Otherwise I'll create a new bug report for this problem.

Thanks
> From: Thomas Lübking  <thomas.luebking@gmail.com>
> Sent: Monday, June 22, 2015, 07:15:37 PM
> To: c.schwarzgruber.cs@gmail.com
> Subject: [kwin] [Bug 323686] After using magic lamp effect: Invalid window 
textured ("black screen") on resume from suspend to ram

> https://bugs.kde.org/show_bug.cgi?id=323686
>
> --- Comment #83 from Thomas Lübking <thomas.luebking@gmail.com> ---
> (In reply to Christux from comment #82)
>
> This interface:
> > if $(qdbus org.kde.kwin /KWin compositingActive)
> > then
> >
> >     qdbus org.kde.kwin /KWin toggleCompositing
> >
> > fi
>
> is gone in KWin 5 - use
> qdbus org.kde.KWin /Compositor suspend
> and
> qdbus org.kde.KWin /Compositor resume
>
> > Unfortunately, this bug is still present in KDE 5. (I use Fedora 22 KDE
> > spin)
> Assuming this is on nvidia (ie. "this bug") there's a chance for a
> workaround in 5.4 (KWin, NOT KF5 which is already at 5.11 or so):
> https://bugs.kde.org/show_bug.cgi?id=344326#c53
>
> The bug itself is -probably, it sorted out- in the nvidia driver and a
> problem when vertex buffer object are copied between system and video RAM.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.