Tag Archives: Wayland

Leap 15.6, Nvidia driver 580 – resume from S3 deep sleep state after suspend to RAM?

Posted on by

Some months ago I wrote a post about a Nvidia option, which at that time helped to overcome a specific problem with a suspend-to-RAM [leading to a deep S3 sleep state] action and a following incomplete resume operation from the S3 state to the original desktop session. The setting “nvidia_modeset vblank_sem_control=0” at least remedied a result which had been described by many users of different Linux flavors: The resume process ended up in a black screen with only a mouse cursor being visible. This situation was difficult to control – and typically one had to reboot the system.

In my experience things have changed a bit since the named post. Therefore, I give a brief summary of other settings below. These settings appear to support relatively stable suspend-to-ram and resume operations on my Leap 15.6 system with my X11-based KDE Plasma a newer Nvidia driver of version 580. However, though not leading to black screens any more, the resume process will not always restore the interrupted KDE/Plasma session. Notably, after a series of extended tests the suspend/resume processes seem to work significantly more stable with Wayland than with X11.

Note, 11/08/25: I had to change this post after some more systematic tests. While I could confirm my general impression that driver Nvidia 580.105 has brought more stability to resume processes from deep S3 sleep, on a X11 based KDE/Plasma desktop, resume processes do fail sometimes – in 20%-30% of the cases. Probably due to race conditions during the restoration of the interrupted KDE/Plasma-session (see below). This did not happen in a series of tests with different sleep time intervals for a Plasma desktop based on Wayland.

Card, driver, services, grub_cmdline

I describe the settings for just one of my systems. The board is an older ASRock Z170 extreme+. The Nvidia card is a 4060 TI. My present Nvidia driver is the proprietary Nvidia driver of version 580.105.08. It was installed from the usual repository. In particular the The RPM “nvidia-driver-G06-kmp-default” is installed. KDE is of version 5.115, Plasma of version 5.27, t5 of version 5.15.12.

Note: I have not checked whether things work on other systems or with Gnome based desktops, yet.

The default grub cmdline contains the parameter setting

nvidia-drm.modeset=1

The services

  • nvidia-suspend.service
  • nvidia-hibernate.service
  • nvidia-resume.service
  • nvidia-persistenced.service
  • nvidia-powerd.service

are all enabled.

Nvidia configuration settings

In the directory “/etc/modprobe.d”, I have a file 50-nvidia.conf”, which contains the following option

blacklist nouveau
options nouveau modeset=0

options nvidia NVreg_DeviceFileUID=0
options nvidia NVreg_DeviceFileGID=33
options nvidia NVreg_DeviceFileMode=0660
options nvidia NVreg_TemporaryFilePath=/var/tmp
options nvidia NVreg_EnableS0ixPowerManagement=1
options nvidia NVreg_PreserveVideoMemoryAllocations=1
options nvidia-drm modeset=1
#
options nvidia_modeset vblank_sem_control=0

Resume-buttons

I usually start suspending to RAM by options offered on the KDE Plasma desktop. But things work also from the command line or with automatic invocation after some idle time of the desktop. My ASRock-board shows that (video) memory contents is written to the system’s root filesystem (see option ) by indicating a respective storage-activity ahead of reaching the S3 state. When the deep suspend state S3 is reached the power button starts blinking.

The default keyboard-button for triggering a resume from sleep is the “blank” key. I can also use the power button on my PC case to start the resume process. If the resume process leads to the old KDE/Plasma session – which it does in more than 60% of the cases with X11 – this session is restored in the state before the suspend-process, with all interrupted processes running again. Independent of the duration of the sleep time. Logs show that a time jump is recognized and that the system adapts to it.

Results after a series of tests on X11 and Wayland based KDE Plasma desktop

In contrast to previous versions of this post, I have now investigated the behavior of the resume processes a bit more systematically, both for X11 and Wayland. For each of the platforms, I have tested the success of suspend/resume processes 15 to 20 times – with growing duration of the sleep interval between 5 minutes up to 40 minutes. The tests also varied with respect to the triggering of the suspend action, regarding both direct user action or, alternatively, an automatic start of a suspend process after some defined idle time. In the latter case a lock/login screen was invoked some minutes before suspend started. (You find respective options in KDE-5’s “systemsettings5”.)

X11-based KDE/Plasma
In the case of X11 a return to the interrupted KDE Plasma session fails in around 30% of the cases. In such cases the resume process ends up in a SDDM login-screen for a new KDE Plasma session. The logs then show that the old Plasma session could not be restored due to some error (see below). The system then obviously turns into a workaround: It forgets the old KDE-session, restarts into the default graphical target and starts SDDM for a new graphical user session. So, the problem with a blank screen and only the mouse cursor blinking appears to have gone (maybe due to the settings “nvidia_modeset vblank_sem_control=0” or due to other improvements; this still has to be checked).

Note, 11/08/25: A previously assumed dependency of the resume success on using the power button or, alternatively, the keyboard to start the resume operation has disappeared after a larger number of tests. There still seems to be a dependency on the duration of the sleep time.

This result means that users of KDE/Plasma should take care of saving all their work before leaving their KDE/plasma desktop unattended with settings that automatically trigger suspend after a defined idle time.

Wayland-based KDE/Plasma
Let me first mention that Wayland meanwhile works really well for the wide range of applications I regularly use. For all the 20 times I tested suspend/resume on Wayland, each trial ended in a successful and complete restoration of the interrupted KDE/Plasma session (which could be entered via login to my KDE session lock-screen).

Race conditions during resume for X11-based KDE/Plasma desktop?

Afterwards, I have checked the logs for X11 and found that the failed resume processes have led to a situation were the X11-session appeared to be broken for certain starting applications as pulseaudio and gkrellm. This may be the result of race conditions between X11-restoration and processes requiring an X11-connection already during resume. In such a case the restart of the default graphical target happened.

Conclusion

The suspend/resume behavior on Leap-systems obviously changes depending on kernel and Nvidia’s driver versions. Presently and on Leap 15.6 systems, we have only reached a relatively stable status regarding suspend-to-RAM and resume for KDE Plasma on a X11-basis: In more than 60% of the cases, the interrupted KDE/Plasma session is fully restored. In other cases I, at least, did not experience blank screens, but a return to the SDDM login-screen for a new desktop session. X11 users should therefore save all their work before leaving the desktop.

The good news is that suspend/resume appears to work flawlessly with Wayland (at least on my conservative Leap system).

I hope this post helps some readers who experience instability problems with suspend/resume on Leap systems with Nvidia graphics cards.

 

Leap 15.6 – upgrade from Leap 15.5 on laptop with Optimus architecture

Posted on by

The last 4 months I was primarily occupied with physics. I got a bit sloppy regarding upgrades of my Linux systems. An upgrade of an rather old laptop to Leap 15.6 was overdue. This laptop had an Optimus configuration: To display graphics one can use either the dedicated Nvidia card or a CPU-integrated Intel graphics or both via an “offload” option for certain applications.

General steps to perform the upgrade

I just list up some elementary steps for the upgrade of an Opensuse Leap system – without going into details or potential error handling:

Step 1: Make a backup of the present installation
You can, for example, create images of the partitions or LVM volumes that contain your Leap-installation and transfer them to an external disk. Details depend of course on whether and how you have distributed system files over partitions or (LVM) volumes. In the simple case of just one partition, you may simply boot a rescue system, mount an external disk to /mnt and then use the “dd”-command;

# dd status=progress if=/dev/YOUR_PARTITION of=/mnt/bup_leap155.img  bs=4M

Step 2: Update the installed packages of the present Leap installation
Perform an update of (all) installed packages – if newer versions are available. Check that your system runs flawlessly afterwards.

Step 3: Change the addresses of repositories to use the ${releasever} variable
You can e.g. use YaST to change the release number in the definition of your repositories’ addresses to the variable ${releasever}. The name of the SLES repository may then look like “https://download.opensuse.org/update/leap/${releasever}/sle/”.

Continue reading →

Opensuse Leap 15.5 – KDE Plasma on Wayland – Nvidia driver, Opera, Chromium, Libreoffice, StandBy

Posted on by

Some days ago I wrote a post on Eclipse and discussed fractional scaling of a selected monitor-screen in a Wayland-session. A reader has written to me and asked whether Wayland works on my system (Opensuse Leap 15.5) reasonably well otherwise.

Frankly, it is a bit like in the early days of KDE4. Wayland works, basically – and compared to Leap 15.4 the situation has improved significantly. But I wouldn’t use Wayland on Leap 15.5, yet, for any professional work under time pressure. During periods of hard work you need to trust your work environment to do what it is supposed to do. You should be able focus a 100% on your tasks – and not loose time with some unexpected glitches in your desktop environment.

However, I use Wayland these days when the risks are low. E.g. when writing blog posts or doing some information gathering on the Internet. Just to become prepared for the day when KDE Plasma switches to Wayland as the standard server for graphical applications. With this post I want to share some experiences with Wayland on a Leap 15.5 system – and give some hints regarding potential problems and workarounds.

Continue reading →

Eclipse – too small icons on high dpi screens – workaround for KDE Plasma by scaling on X11 and Wayland

Posted on by

I have to work with Eclipse (version 4.32) again for a while. After two days of relatively intensive work, I am a bit frustrated. One reason is the small size of the icons – 16×16 px. Not only in the main icon taskbar. There are minuscule symbols elsewhere – e.g. in the bar on the left side of the editor section. Regarding e.g. the tiny symbol for code folding: You can almost not see the “+” or “-” symbols on a high resolution screen …

One can scale almost all font-sizes within Eclipse – but not such a basic thing as the icon/symbol size or the icon bar height.

I have three QHD screens (2560×1440) at my present workplace. At another site there are 2 4K screens. The following image can give you an impression for the QHD situation – if you have a QHD, UHD or 4K screen yourself and not zoomed the browser contents already. For screens with lower resolution see below.

Before you say this looks quite OK, check the following:

  • Open this post on a desktop screen in a window wider than 800 px.
  • Enforce normal content size size in your browser (no zoom! Ctrl-0).
  • Get a natural distance to your working QHD, UHD or 4K monitor (like 80+ cm). In case you have a QHD screen you get already the right impression.
  • Users who just have a monitor with a 1920×1200 resolution must in addition downscale their browser contents to around 80% (QHD) or 55% (UHD, 4K) to get the right impression of the problem. (After Ctrl-0)
  • Folks with QHD get the right 4K impression by scaling down to 66%. (After Ctrl-0)

While for QHD the working conditions may still appear to be OK, you get a real problem for UHD and 4K resolutions. The font-size may still be OK (after having adapted it). The unadaptable symbol sizes, however, are far too small. At least in my opinion. But even on my standard QHD screens I personally do not feel comfortable after a while.

In this post I want to share some workarounds. The methods described may be interesting for other GTK applications, too. Keep in mind that the images in this post may give you a wrong impression if you zoomed the browser contents. But later on, when I demonstrate the effect of some measures, only relative sizes of fonts and icons are of interest.

Continue reading →

Opensuse Leap 15.4 on a PC – II – Plasma, Gnome, flatpak, Libreoffice and others on (X)Wayland?

Posted on by

In the last post of this series

Upgrade to Opensuse Leap 15.4 – I – a look at repositories, Nvidia, Vmware WS, KVM, Plasma widgets

we saw that an upgrade from Leap Opensuse 15.3 to Leap 15.4 is a relatively smooth operation. After the basic upgrade I wanted to look a bit at an interesting detail – namely (X)Wayland. And got surprised – positively and negatively. This post summarizes some of my experiences.

Nvidia and Wayland

For a long time it was almost impossible to use Wayland in combination with Nvidia and KDE. Which mostly was the fault of Nvidia. See an Heise article on this topic here. See also the experience of a Gnome user here – although I do not share his bad experience with a X11-based KDE Plasma on Nvidia. For years I have not seen a realistic chance for a productive use of Wayland on my PCs and laptops with Nvidia-cards. KDE PLasma did not work at all on Wayland. Also with Gnome I experienced terrible difficulties. But Nvidia has improved its support for Wayland significantly in 2022, starting with driver version 470. For Nvidia driver version 525 we would expect some stability.

Continue reading →