Resuming from suspend to RAM gives a black screen with a few faint artifacts at the bottom edge of the screen where the panel resides. Turn off KDE Desktop Effects (Alt+F12) and resume works perfectly. Problem is consistent with Desktop Effects enabled. Recovery from the black screen requires killing the X-server. Reproducible: Always Steps to Reproduce: 1. Enable Desktop Effects. 2. Click suspend to RAM. 3. Attempt to wake the computer from sleep. Actual Results: Occurs every time. Expected Results: Expected is password prompt. Occurred after recent update, possibly the update to 4.13.3, also seemed to coincide with kernel update from 3.15.9 to 3.16.2, though problem also occurs with earlier kernels when tested.
nvidia? -> see https://forum.kde.org/viewtopic.php?f=111&t=121590
I am experiencing a very similar bug, however, it does not happen 100% of the time. That is, resume from suspend fails anywhere between 10% and 50% of the time. When resume from suspend fails my screen is mostly black but with distorted images as depicted here: http://dickens.com/images/corrupted.jpg I am running OpenSUSE 13.1, KDE 4.14.1, my kernel is Linux 3.11.10-21-desktop and nVidia driver version 337.25. However, I have experienced this bug with a wide variety of kernels and nVidia drivers over the past 6 months as I have researched this problem. At first, I thought that this was a bug with the proprietary nVidia driver and/or the kernel so I submitted bug reports for each with nVidia and OpenSUSE respectively. Both the nVidia and OpenSUSE developers responded that the bug was not in the nVidia driver and the kernel respectively. So, I then started investigating KDE as the culprit. I have found that the bug can be completely avoided by simply toggling off compositing (desktop effects) prior to suspend with "qdbus org.kde.kwin /KWin org.kde.KWin.toggleCompositing". Also, I have found that "kwin --replace" will fix the corrupted suspend state when it occurs and I have programmed a function key with "kwin --replace" which I have used to correct the problem when it occurs. However, if the user is locking the screen upon suspend then the user must blindly enter their password at the corrupted screen prior to executing "kwin --replace" with the function key. Here are two threads in user forums where this bug is being discussed: https://forums.opensuse.org/showthread.php/494706-openSUSE-13-1-KDE-inconsistant-resume-from-Suspend-to-RAM https://forum.kde.org/viewtopic.php?f=111&t=121590 Everybody that I have seen reporting this problem are running KDE. Since most all of the users who are reporting this problem are running KDE and toggling compositing/desktop effects prior to suspend prevents the bug from occurring and "kwin --replace" also fixes it, then I believe that it is safe to say that KDE is causing the problem. I am currently using the following script to suspend with the screen locked and it successfully resumes from suspend 100% of the time: #!/bin/sh qdbus org.kde.kwin /KWin org.kde.KWin.toggleCompositing /usr/lib64/kde4/libexec/kscreenlocker_greet --immediateLock & sleep 2 /usr/bin/systemctl suspend qdbus org.kde.kwin /KWin org.kde.KWin.toggleCompositing So, a simple solution woud be for the KDE developers to simply embed a similar script that turns off compositing prior to using systemd to suspend (/usr/bin/systemctl suspend) and then turns compositng back on when the user resumes from suspend. Just my 2 cents.
Of course, if you simply avoid a GL context, you won't have any trouble with the GL driver ... But if the only way out is indeed restarting the X11 server, that's most certainly not a client bug. You just don't lock+suspend while playing quake ;-) However, also check bug #323686 - it's maybe triggered by the magic lamp effect alone? (Restart the compositor after deactivating the effect or please confirm that it happens although you're not using the magic lamp effect)
Hi Thomas, Thanks for the reference to bug #323686. I have been running with the Magic Lamp effect. So, I have disabled it and will test it with the stock KDE suspend function key. I will let you know how it goes.
Its now been two days since I turned my Magic Lamp effect off and I haven't had a failed resume from suspend yet. I will report back in a couple of days and if I haven't had a failure then I will conclusively say that the Magic Lamp effect was causing my problems.
I am 100% convinced that the KDE Magic Lamp effect was the culprit causing the resume from suspend problems. I have been running without the Magic Lamp now for 5 days without a single failure resuming from suspend.
*** This bug has been marked as a duplicate of bug 323686 ***