Hint: After some experiments and further Internet digging, this post was rewritten and supplemented on the 5th of March, 2025. Sorry for any inconvenience.
—–
Recently, I have upgraded Opensuse Leap to version 15.6 on 5 PC-systems – all with (different) Nvidia graphic cards. I use KDE/Plasma on all these systems.
My daily working system is equipped with a 4060 TI Nvidia card. Nvidia drivers of version 570.124.06-1 on this particular system came from the Nvidia CUDA repository for Opensuse system at
https://developer.download.nvidia.com/ compute/ cuda/ repos/ opensuse15/ x86_64.
I sadly must say that the named particular driver, but also the present Nvidia drivers of version 570.86.16 on other systems, are at least in their corporation with the Linux kernel (6.4.0) and other components of the present Leap 15.6, unreliable or even buggy (for KDE/Plasma):
The resume process from “Suspend to RAM” does not work reliably on any of the systems.
I get black screens with only the mouse cursor showing up, on other systems totally black screens, on some systems the SDDM login screen turns up after more than 2 or 3 minutes wait time – but not always.
Unfortunately, after many experiments, I have no real solution for this. You can try to go backwards to driver version 550 – but due to complicated package dependencies this is no easy endeavor either.
Therefore: Linux admins who have not yet updated Nvidia drivers to version 570 should keep their older versions.
Version 570 is the latest available one of the Nvidia driver in the Opensuse repositories. It is not the official stable version – which actually is 550. Why the Opensuse people have placed the 570 version already into their repository can be discussed.
As energy saving, in my opinion, is something important, I hope that both driver developers and Opensuse developers solve this problem in the near future.
Workaround
A workaround is described at
https://forums.developer.nvidia.com/t/black-screen-with-cursor-after-sleep/319473
It requires the following entry in a file which you place into the directory “/etc/modprobe.d”. Alternatively, you can modify one of the files already existing there accordingly:
options nvidia_modeset vblank_sem_control=0
You have to reboot after these changes. Afterward the resume process worked on a system with a 4060 TI graphics card. Addendum, 06.03.2025: The workaround helped on my other Linux systems, too.
However, there seem to be disadvantages for advanced GPUs. See the comments of the moderator “aritger” in the forum behind the given link and some information on GSP firmware. For my simple consumer card I could not see negative impacts, so far …
Emergency recovery – works sometimes
In case the named workaround does not help you:
If your desktop is not locked and does not require a new authentication at resume – you may have a chance with the following approach:
After a resume process, ending up in a black scree, I could change to TTY-1 via Ctrl-Alt-F1, log in as the current X11/Plasma-user there and enter the commands
killall plasmashell kstart5 plasmashell &
This allowed for a change back to the graphical TTY (apparantly TTY2) via Ctrl-Alt-F2 to now find a partially working desktop screen there. I could enter commands in an already open terminal window or start one via ALT-F2 and entering “konsole” in the input field. Then I repeated the commands named above again to get a fully running desktop back.
However, this workaround only works once – after a second “suspend to RAM” it failed! And it is no solution in case you have a (standard) setup which requires an authentication after resume from suspend.
To me, it seems that the problem is somehow related to starting the plasmashell during the resume process on the correct TTY.
What about the resume process with Gnome instead of KDE?
I have only tested “suspend to RAM” and “resume” for Gnome on X11. There the resume process takes a while, but in the end (after a bit more than 10 secs) everything is OK. I did get a fully working desktop back.
Whatever this means regarding the cause of the problem ….
