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.
Some info on my graphics configuration
The graphics card is a Nvidia 4060 TI. My desktop stretches across three monitor screens. The screen order and the screen positions were set by KDE’s “systemsettings” (“display and monitor”). “Nvidia X server settings” displays consistent information about the .
My Leap 15.5 is primarily based on the SLES update repository. In addition to the SLES packages I use RPMs from the following Opensuse repositories: Update, Backport, Non-OSS (for Opera), Mozilla (for FF), Packman (audio), Security, Multimedia (for a few audio applications) and PHP. And, last but not least, the Nvidia Community repository for Nvidia drivers – plus Nvidia’s CUDA repository for Machine Learning support. Regarding sound plain Pulseaudio still does its job (after I had fought with it a long time). I postpone fiddling with pipewire or pipewire-PA settings as long as possible.
The most important packages regarding Wayland are located in the SLES repository. Do not mix the Wayland packages with packages from other repositories (in YaST’s RPM management search for “wayland” and check versions). My installed Wayland packages are (you may click on it to get an enlarged view):
The other important point regarding Wayland is the Nvidia driver. Nvidia’s Wayland support has eventually become better over the last two years. Still, you have to be careful with the driver selection.
The present Nvidia driver offered via the community repository for Leap 15.5 has a version number 550.100. I have also tried the latest driver version 560.35 from the CUDA repository. While the support for Wayland seems to be a bit better with driver 560, it has some other serious disadvantages. E.g. the return from StandBy mode does not work correctly – neither on X11 nor Wayland. I, therefore, have returned to Nvidia’s driver version 550.100 again. The experience in this post are based on this particular driver version.
Under certain conditions the Nvidia driver of version 550.100 has problems to restart my multi-screen Plasma on Wayland correctly from Stand-By mode. But there are workarounds. See below.
Methods to start Wayland
Wayland session start via SDDM
The easiest way to start a KDE Plasma session on a Wayland-server is of course via the display and login manager “SDDM“. As soon as you have installed the package “plasma5-session-wayland” you should find an option there for starting “plasma(wayland)“.
Wayland session start via CLI
Another important way to start a Wayland session is a manual start via a TTY and the command line. This way is important because of the following reason: It may happen that you destroy your Plasma desktop on Wayland by some accident. Then it may never come up again if you try to start Plasma (Wayland) via SDDM. Such “destructions” may occur due to bugs, but also after non-fitting package updates.
I have actually experienced multiple situations in my multi-screen environment where I got stuck in a permanent loop between restarting the graphical interface without success (some screens active, some not) and intermediate core dumps followed by the next restart trial. Not funny at all. I had to perform a RESET of the whole system and boot it up again into a non-graphical systemd target. In this situation a partial startup of Wayland was still possible via the command line from a TTY. And this ma Then move e.g. to TTY3 (Ctrl-Alt_F3) and login with your UID. Then start a Wayland session (on TTY3) with “dbus-run-session” should not be necessary any longer, but it does no harm either. You can try it without …. On my three screen the Plasma desktop with its background images, my taskbars and the applications gathered in KDE’s autostart folder come up. But all applications are placed on the first of my 8 virtual desktops. Wayland appears not to remember the applications started in the last Wayland session. Neither their original positions on the available virtual desktops. There is no native mechanism for this, yet. In case you could work in a normal way during your Wayland session and if you could end it by logging out, everything should be OK for another start of your next Wayland session from the TTY’s command line. To be on the safe side you may first go to TTY2 again and re-enter “init 3” there. Then use the “startplasma-wayland” command on the other TTY to start your next Wayland session manually. In case your Wayland Plasma session does no longer start from SDDM, GDM, etc., you may have destroyed some Plasma settings for Wayland (and Plasma seems to remember such things). I have experienced multiple situations where I ran into endless loops switching between a partially started Plasma desktop, coredumps, and restart trials. During these loops no trial to change to a TTY (e.g. to TTY3 by pressing CTRL-Alt-F3) worked any longer. I had to perform a hard reset of the whole PC system. Then I could boot it up again into the graphical target with SDDM – but I switched in the end to a non-graphical target. On a Leap system, you can e.g. achieve this from your desktop manager screen by pressing “CTRL-ALT-F2”, logging in on the ASCII screen of TTY2 as root and entering “init 3”. After that you again switch to another TTY (e.g. TTY3), login with your normal UID and enter “startplasma-wayland”. This may start Wayland at least in parts. When I had arrived at this point after severe Wayland/Plasma problems on my system, two (out of my 3) screens remained totally black, but on one screen some standard applications appeared. On this screen I was able to open a “konsole” terminal window via krunnner (ALT-F2). This terminal window allowed me to kill the present plasmashell and to restart it again: This procedure fortunately led to a normal KDE Plasma behavior on Wayland afterward. I then logged out of the session and could restart it normally again – either via “startplasma-wayland” from a TTY CLI or from SDDM. There are some applications which flicker or distort the cursor – until you click into them. The reasons are different. You should also be aware of the fact that not all applications you may want to run have been turned into applications with native Wayland support, yet. When I first started Wayland after having worked with my Plasma desktop on X11, I was surprised that all the applications I had opened during the X11-based session were opened again. But this positive experience did not last for long. The first point is that all the applications were opened on the very first of my available 8 virtual desktops – and there on the rightmost screen. It was not really funny to rearrange my apps such that they appeared on their original virtual desktops again. (I did not yet test the behavior of so called Plasma “activities” on Wayland.) The second point is that when you log out of a Wayland session and log in again, then, aside of defined autostart applications, only Firefox windows are restored at all. As said: In its present state Wayland neither remembers which applications were open at the end of your last Wayland Plasma session, nor which position they had on which virtual desktop (or Plasma activity). For me this is almost a NO GO in a professional context. When doing e.g. development work, I want to get back all the applications I had opened in my last session – and on those virtual desktops where I had placed them. My desktop stretches across 3 monitor screens. Restarting the multi-screen desktop when coming back from StandBy mode did not work at all with driver version 560.35 on my system. It ended up in 3 black and unusable screens. Both on X11 and on Wayland. However, Nvidia driver version 550.100 supported a complete and flawless return both from StandBy and Hibernation modes for X11 sessions. Under Wayland a direct transition from the desktop or from a login-screen spanned over all monitors to the StandBy mode and back to the working desktop or the login screen, respectively, worked flawlessly with driver version 550. But, even with version 550.100, there is a problem when some planned and automatic energy saving actions occur ahead of the transition to StandBy mode: My system is set up such that it first switches to the login screen after some time without activity. A bit later all of my 3 monitors are switched off. And only a while later the transition into StandBy mode occurs. From this you start your session again by pressing the power button. On a Wayland driven Plasma desktop this chain of events leads to a startup from StandBy with only the main monitor screen getting illuminated. The other screens remain dark. This does not happen for X11 – only for Wayland. Workaround for partial startup after StandBy: The Opera browser has become one of my favorite browser over the years. The main reason is that it allows to organize tabs and opened links in a very reasonable way. When you open it as usual on a Wayland desktop you may experience problems with flickering contents, borders and a trace of distorted mouse cursor icons. However, Opera supports Wayland. You have to open it with Wayland support from the command like like this: Then Opera will behave perfectly normal! You should add the options to special launcher icons on your Plasma desktop for Wayland. Chromium and Opera use the same engine. Therefore the startup procedure for Chromium is the same as for Opera: Libreoffice [LO] works as long as you do not set a fractional scaling factor on an individual monitor screen – a measure I have discussed in my previous post about Eclipse. Fractional scaling per monitor screen of your desktop can be done via “systemsettings” >> “Display and Monitor”. The problem is that LO does not scale correctly on the different screens displaying your KDE Plasma desktop. However, there is a workaround: When you open the YaST2 interface as usual on a Wayland desktop, you get flicker effects. You must click into the application windows to stop that. The problem here is obviously that you run the program as root – and the respective shell does not realize that yast2 should run on a Wayland display as it has different environment variables. The easiest way to circumvent this is by starting YaST from the command line via The “-E” option preserves environment settings. Other solutions are discussed here. Wayland on an Opensuse Leap 15.5 system with an Nvidia graphics card is worth trying it out. With the Nvidia driver version 550.100 KDE Plasma on Wayland works relatively stable. But there are still major deficits regarding a usage of Wayland in a professional environment.
myself:~> dbus-run-session startplasma-wayland &
How to use the manual start in case of major problems with a Wayland startup?
myself:~> kquitapp5 plasmashell || killall plasmashell && kstart5 plasmashell
Observations during normal Wayland Plasma sessions
No restoration of the applications of your last Wayland session
Partial restart from StandBy mode for Wayland
On the active screen try to open KDE’s “systemsettings” and go to the “display and monitor” settings there. If you do not see the systemsettings window (because it was placed onto an inactive dark screen) you might still be able to find an icon for it in the taskbar. Right click on it – go to “more” and find the option for moving the window. Try to get the systemsettings window onto the illuminated monitor screen with some mouse movements. Then change the arrangement of the screens a bit and apply the new settings. In my case all my monitor screens got active again during this action. Afterward I could set their arrangement back to normal – and work again on my desktop extended across all monitor screens. Opera browser
myself:~> opera --enable-features=UseOzonePlatform --ozone-platform=wayland &
Chromium browser
myself:~> chromium --enable-features=UseOzonePlatform --ozone-platform=wayland &
Libreoffice – problem with fractional screen scaling on a multiscreen desktop
myself:~> WAYLAND_DISPLAY= SAL_USE_VCLPLUGIN=kf5 /usr/bin/libreoffice &
Yast2 flickers … – solution
myself:~> sudo -E yast2 &
Conclusion