Bug 323686 - After using magic lamp effect: Invalid window textured ("black screen") on resume from suspend to ram
Summary: After using magic lamp effect: Invalid window textured ("black screen") on re...
Status: RESOLVED DUPLICATE of bug 344326
Alias: None
Product: kwin
Classification: Plasma
Component: effects-various (show other bugs)
Version: 4.11.0
Platform: Gentoo Packages Linux
: NOR major with 7 votes (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 339030 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-08-18 19:17 UTC by Māris Nartišs
Modified: 2015-06-22 20:07 UTC (History)
21 users (show)

See Also:
Latest Commit:
Version Fixed In:
thomas.luebking: NVIDIA+


Attachments
kwin output while launching and resulting in a black screen (9.57 KB, text/plain)
2013-08-18 19:19 UTC, Māris Nartišs
Details
KWin Support Output - NVidia 319.32 (5.56 KB, text/plain)
2013-08-29 14:36 UTC, Stefan Werner
Details
Temporary fix (485 bytes, text/x-sh)
2013-11-06 18:25 UTC, Stefan Werner
Details
Distorted screen on resume from suspend (678.23 KB, image/png)
2015-06-22 17:06 UTC, Christux
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Māris Nartišs 2013-08-18 19:17:02 UTC
Since upgrade to 4.11, after longer suspension (30 min or more), screen comes up as black with garbage all around screen edges. 
Mouse cursor is fine. Entering password to unlock session works and desktop session is restored, still whole screen is black but cursor changes shape when hovering over screen areas containing input fields -> desktop is running but is not rendered.
It is possible to switch to terminal and run "killall kwin". After that all desktop applications are visible, still no window manager. Starting TWM allows to resume desktop use. Subsequent launches of KWin most of times return back to black screen. Killing kwin allows to get desktop back.
Log files show no issues with driver, crashes or anything else hinting driver related issue.

Reproducible: Sometimes

Steps to Reproduce:
1. Suspend computer for longer time;
2. Resume;
3. Repeat steps 1 and 2 as sometimes it works.
Actual Results:  
Screen is black.

Expected Results:  
Screen content is rendered in appropriate colors not all black.

Information for a running state (non-black) kwin:
qdbus org.kde.kwin /KWin supportInformation
KWin Support Information:
The following information should be used when requesting support on e.g. http://forum.kde.org.
It provides information about the currently running instance, which options are used,
what OpenGL driver and which effects are running.
Please post the information provided underneath this introductory text to a paste bin service
like http://paste.kde.org instead of pasting into support threads.

==========================

Version
=======
KWin version: 4.11.0
KDE SC version (runtime): 4.11.00
KDE SC version (compile): 4.11.00
Qt Version: 4.8.5

Options
=======
focusPolicy: 0
nextFocusPrefersMouse: false
clickRaise: true
autoRaise: false
autoRaiseInterval: 0
delayFocusInterval: 0
shadeHover: false
shadeHoverInterval: 250
separateScreenFocus: false
placement: 4
focusPolicyIsReasonable: true
borderSnapZone: 10
windowSnapZone: 10
centerSnapZone: 0
snapOnlyWhenOverlapping: false
showDesktopIsMinimizeAll: false
rollOverDesktops: true
focusStealingPreventionLevel: 3
legacyFullscreenSupport: false
operationTitlebarDblClick: 
commandActiveTitlebar1: 0
commandActiveTitlebar2: 30
commandActiveTitlebar3: 2
commandInactiveTitlebar1: 4
commandInactiveTitlebar2: 30
commandInactiveTitlebar3: 2
commandWindow1: 7
commandWindow2: 8
commandWindow3: 8
commandWindowWheel: 31
commandAll1: 10
commandAll2: 3
commandAll3: 14
keyCmdAllModKey: 16777251
showGeometryTip: false
condensedTitle: false
electricBorderMaximize: true
electricBorderTiling: true
electricBorderCornerRatio: 0.25
borderlessMaximizedWindows: false
killPingTimeout: 5000
hideUtilityWindowsForInactive: true
inactiveTabsSkipTaskbar: false
autogroupSimilarWindows: false
autogroupInForeground: false
compositingMode: 1
useCompositing: true
compositingInitialized: true
hiddenPreviews: 1
unredirectFullscreen: false
glSmoothScale: 2
colorCorrected: false
xrenderSmoothScale: false
maxFpsInterval: 16666666
refreshRate: 0
vBlankTime: 6000000
glDirect: true
glStrictBinding: false
glStrictBindingFollowsDriver: true
glLegacy: false
glCoreProfile: false
glPreferBufferSwap: 99

Screen Edges
============
desktopSwitching: false
desktopSwitchingMovingClients: false
cursorPushBackDistance: 
timeThreshold: 150
reActivateThreshold: 350
actionTopLeft: 0
actionTop: 0
actionTopRight: 0
actionRight: 0
actionBottomRight: 0
actionBottom: 0
actionBottomLeft: 0
actionLeft: 0

Screens
=======
Multi-Head: no
Number of Screens: 1
Screen 0 Geometry: 0,0,1440x900

Decoration
==========
Current Plugin: kwin3_aurorae
Shadows: yes
Alpha: yes
Announces Alpha: yes
Tabbing: no
Frame Overlap: yes
Blur Behind: yes

Compositing
===========
Qt Graphics System: native
Compositing is active
Compositing Type: OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro NVS 160M/PCIe/SSE2
OpenGL version string: 3.3.0 NVIDIA 325.15
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler
Driver: NVIDIA
Driver version: 325.15
GPU class: Unknown
OpenGL version: 3.3
GLSL version: 3.30
X server version: 1.14.2
Linux kernel version: 3.9
Direct rendering: yes
Requires strict binding: no
GLSL shaders:  yes
Texture NPOT support:  yes
Virtual Machine:  no
OpenGL 2 Shaders are used

Loaded Effects:
---------------
kwin4_effect_zoom
kwin4_effect_slidingpopups
kwin4_effect_login
kwin4_effect_minimizeanimation
kwin4_effect_screenshot
kwin4_effect_translucency
kwin4_effect_maximize
kwin4_effect_fade
kwin4_effect_highlightwindow
kwin4_effect_taskbarthumbnail
kwin4_effect_dialogparent
kwin4_effect_presentwindows
kwin4_effect_blur
kwin4_effect_logout
kwin4_effect_dashboard
kwin4_effect_screenedge
kwin4_effect_startupfeedback
kwin4_effect_kscreen

Currently Active Effects:
-------------------------
kwin4_effect_blur

Effect Settings:
----------------
kwin4_effect_zoom:
zoomFactor: 1.2
mousePointer: 0
mouseTracking: 0
enableFocusTracking: false
followFocus: true
focusDelay: 350
moveFactor: 20
targetZoom: 1

kwin4_effect_slidingpopups:
fadeInTime: 50
fadeOutTime: 50

kwin4_effect_login:

kwin4_effect_minimizeanimation:

kwin4_effect_screenshot:

kwin4_effect_translucency:

kwin4_effect_maximize:

kwin4_effect_fade:

kwin4_effect_highlightwindow:

kwin4_effect_taskbarthumbnail:

kwin4_effect_dialogparent:

kwin4_effect_presentwindows:
layoutMode: 0
showCaptions: true
showIcons: true
doNotCloseWindows: false
ignoreMinimized: false
accuracy: 20
fillGaps: true
fadeDuration: 30
showPanel: false
leftButtonWindow: 1
rightButtonWindow: 2
middleButtonWindow: 0
leftButtonDesktop: 2
middleButtonDesktop: 0
rightButtonDesktop: 0
dragToClose: false

kwin4_effect_blur:
blurRadius: 12
cacheTexture: true

kwin4_effect_logout:
useBlur: true

kwin4_effect_dashboard:
brightness: 0.5
saturation: 0.5
blur: false

kwin4_effect_screenedge:

kwin4_effect_startupfeedback:

kwin4_effect_kscreen:
Comment 1 Māris Nartišs 2013-08-18 19:19:24 UTC
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.
Comment 2 Martin Flöser 2013-08-18 19:28:33 UTC
> 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.
Comment 3 Thomas Lübking 2013-08-18 20:48:35 UTC
> 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)
Comment 4 Māris Nartišs 2013-08-25 09:43:10 UTC
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 ?
Comment 5 Stefan Werner 2013-08-29 14:36:09 UTC
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}
Comment 6 Myrmidon83 2013-08-31 09:06:37 UTC
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.
Comment 7 Thomas Lübking 2013-08-31 12:41:30 UTC
(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)
Comment 8 m1st0 2013-10-21 23:11:44 UTC
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.
Comment 9 m1st0 2013-10-21 23:19:10 UTC
(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
Comment 10 Thomas Lübking 2013-10-21 23:44:10 UTC
(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.
Comment 11 m1st0 2013-10-22 00:11:59 UTC
(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.
Comment 12 Thomas Lübking 2013-10-22 00:26:59 UTC
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.
Comment 13 m1st0 2013-10-22 03:27:55 UTC
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.
Comment 14 cobalt 2013-10-28 19:10:29 UTC
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.
Comment 15 Thomas Lübking 2013-10-28 20:11:13 UTC
(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?
Comment 16 cobalt 2013-10-28 20:37:18 UTC
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.
Comment 17 Thomas Lübking 2013-10-28 20:46:51 UTC
(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?
Comment 18 cobalt 2013-10-28 21:04:40 UTC
(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.
Comment 19 Myrmidon83 2013-10-28 21:43:14 UTC
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
Comment 20 Myrmidon83 2013-10-28 21:46:39 UTC
I should add that I'm using Linux Mint 13 with kubuntu backports enabled,
3.10.9 kernel
Nvidia 319.32
Comment 21 cobalt 2013-10-28 22:19:19 UTC
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.
Comment 22 Thomas Lübking 2013-10-29 20:08:51 UTC
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...)
Comment 23 Myrmidon83 2013-10-29 20:28:20 UTC
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.
Comment 24 Thomas Lübking 2013-10-29 20:59:42 UTC
(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.
Comment 25 Myrmidon83 2013-10-30 17:31:36 UTC
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?
Comment 26 Kristian 2013-11-01 09:48:51 UTC
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).
Comment 27 Kristian 2013-11-01 10:12:22 UTC
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?
Comment 28 Thomas Lübking 2013-11-01 15:30:24 UTC
 [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 ;-)
Comment 29 Myrmidon83 2013-11-01 17:14:16 UTC
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.
Comment 30 cobalt 2013-11-01 18:48:25 UTC
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.
Comment 31 cobalt 2013-11-01 18:49:24 UTC
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.
Comment 32 Thomas Lübking 2013-11-01 19:26:23 UTC
(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.
Comment 33 cobalt 2013-11-01 19:32:37 UTC
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.
Comment 34 Myrmidon83 2013-11-02 00:28:09 UTC
'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.
Comment 35 Kristian 2013-11-02 17:56:53 UTC
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.
Comment 36 Myrmidon83 2013-11-05 17:35:33 UTC
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?
Comment 37 Thomas Lübking 2013-11-05 18:03:47 UTC
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.
Comment 38 Myrmidon83 2013-11-06 17:56:28 UTC
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?
Comment 39 Stefan Werner 2013-11-06 18:24:21 UTC
(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!
Comment 40 Stefan Werner 2013-11-06 18:25:54 UTC
Created attachment 83382 [details]
Temporary fix
Comment 41 Myrmidon83 2013-11-06 20:20:02 UTC
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'.
Comment 42 Myrmidon83 2013-11-06 20:23:41 UTC
Forget that, for some reason when I was editing I forgot to change it to executable, doh!
Comment 43 Myrmidon83 2013-11-06 20:31:05 UTC
Script is looking to be working good Stefan!  :D  I'll keep you updated.
Comment 44 Thomas Lübking 2013-12-05 20:43:41 UTC
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 :-(
Comment 45 Daniel Faust 2013-12-07 17:11:14 UTC
(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.
Comment 46 Daniel Faust 2013-12-07 20:39:28 UTC
Ok, that was too fast, it happened again.
But it seems to have gotten less. Well more testing would be necessary ...
Comment 47 cobalt 2013-12-12 19:08:06 UTC
Using compiz instead of kwin also fixes the problem
Comment 48 Sergey Stepanov 2013-12-22 19:36:17 UTC
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.
Comment 49 Matthew Stapleton 2014-02-26 23:42:56 UTC
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.
Comment 50 Andreas Hermann 2014-05-06 14:07:22 UTC
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.
Comment 51 Thomas Lübking 2014-05-07 13:16:31 UTC
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.
Comment 52 Andreas Hermann 2014-05-07 21:11:08 UTC
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.
Comment 53 Thomas Lübking 2014-05-08 11:22:15 UTC
(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
Comment 54 Andreas Hermann 2014-05-12 09:39:21 UTC
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.
Comment 55 Stuart Citrin 2014-07-19 13:28:49 UTC
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
Comment 56 Thomas Lübking 2014-07-19 13:34:36 UTC
(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
Comment 57 Stuart Citrin 2014-07-20 20:38:01 UTC
(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).
Comment 58 Stuart Citrin 2014-07-21 13:37:52 UTC
Can now reproduce on Archlinux also:
linux 3.15.5
nvidia 340.24
kdebase-workspace 4.11.10  (which is latest available on ARCH )
Comment 59 Antonio Orefice 2014-09-18 07:50:45 UTC
I've to confirm that disabling magic lamp seems to workaround the issue.
Comment 60 Thomas Lübking 2014-09-18 10:42:36 UTC
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.
Comment 61 cobalt 2014-09-20 19:04:44 UTC
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.
Comment 62 cobalt 2014-09-20 19:19:56 UTC
This bug is most likely duplicate of the bug 322975
Comment 63 Gordon 2014-09-24 10:31:07 UTC
Turning the Magic Lamp effect off solved my resume from suspend problem too!
Comment 64 Thomas Lübking 2014-09-24 14:16:11 UTC
*** Bug 339030 has been marked as a duplicate of this bug. ***
Comment 65 Gordon 2014-09-29 13:48:38 UTC
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
Comment 66 Antonio Orefice 2014-09-29 14:02:34 UTC
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
Comment 67 Antonio Orefice 2014-09-29 14:03:06 UTC
...of course a proper fix upstream would be better
Comment 68 Thomas Lübking 2014-09-29 14:23:13 UTC
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)
Comment 69 Tsu Jan 2015-01-05 20:37:10 UTC
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.
Comment 70 Tsu Jan 2015-01-09 17:07:52 UTC
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.
Comment 71 Radics Péter 2015-01-21 16:03:16 UTC
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.
Comment 72 Tsu Jan 2015-01-21 17:24:10 UTC
> (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.
Comment 73 Thomas Lübking 2015-01-21 17:28:07 UTC
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)?
Comment 74 Tsu Jan 2015-01-21 18:15:43 UTC
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).
Comment 75 cobalt 2015-01-21 22:52:29 UTC
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).
Comment 76 Thomas Lübking 2015-02-19 14:11:43 UTC

*** This bug has been marked as a duplicate of bug 344326 ***
Comment 77 Gordon 2015-02-19 15:12:04 UTC
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.
Comment 78 Tsu Jan 2015-02-27 09:57:47 UTC
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.
Comment 79 Thomas Lübking 2015-02-27 11:34:37 UTC
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)'
Comment 80 Tsu Jan 2015-02-27 13:07:16 UTC
(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,
Comment 81 Tsu Jan 2015-02-27 13:20:01 UTC
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,
Comment 82 Christux 2015-06-22 17:06:37 UTC
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)
Comment 83 Thomas Lübking 2015-06-22 19:15:37 UTC
(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.
Comment 84 JonnyRobbie 2015-06-22 19:28:17 UTC
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
Comment 85 Thomas Lübking 2015-06-22 20:04:26 UTC
(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)
Comment 86 Christux 2015-06-22 20:07:05 UTC
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.