In the last post of this series
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.
Leap 15.4 provides Wayland for Plasma and Gnome “natively” or in the form of Xwayland (for more information on Xwayland see here. Xwayland realizes an X-Server on top of the Wayland compositor and thus allows for a smooth transitions of originally X-dependent applications. Applications do not need to be native Wayland applications. Already adapted applications can however directly use Wayland-features. While I saw some trouble with Leap 15.3 and native Wayland, I thought it might be interesting to try KDE/Plasma 5.24 on Qt5 and XWayland. With some of my standard applications. If that worked well it would be worthwhile to engage in tests on native Wayland.
My main message is: Most KDE/Plasma tools work well on Xwayland (and even native Wayland). And most of my applications for daily work. But I have to mention the exception of Libreoffice [LO] running on Qt5. However, even this problem is no real obstacle for using Xwayland if you like to deviate from LO’s standard installation on Opensuse.
A natural choice to work with native Wayland and Libreoffice seems to be Gnome. I only tested Gnome on Wayland a bit – overall it seems to work nicely together with an Nvidia card these days. And on Gnome LO works as a charm – without any changes to the standard installation. A pity that I do not really like Gnome ….
How to choose Xwayland or Wayland?
You have to install certain RPMs to ensure that (X)Wayland is supported by your desktop environment on your Leap installation. Search for “wayland” in Yast’s software management application. The most important one has the name “xwayland”:
Also Qt5, KDE, Plasma and Gnome require additional RPMs to support (X)Wayland. After the installation SDDM and other desktop display managers (e.g. gdm) offer you options to start a desktop session with Plasma or Gnome3 on X11 or (X)Wayland – if supported. (XFCE users will have to wait a bit still as XFCE is planned as a native Wayland application.)
What about “native” Wayland? I should mention a problem here: For the time being I have difficulties to define and check what a real native Wayland session for KDE/Plasma on Opensuse is. If you de-install the RPM “xwayland” then automatically “xorg-x11-server-wayland” is installed. SDDM afterward offers you “Plasma on Wayland” (not Xwayland) – but who knows.
I have had no time to dig into details, but Opensuse may do some special patching for Wayland. This becomes clear from a discussion for which I have a given a link at the end of this post. Nevertheless: A deinstallation of the “xwayland” RPM makes a difference. E.g. and funny enough this has a major impact on Suse’s YaST: The graphical YaST version (yast2) does not start in a Wayland session afterward.
Therefore, I call a native Wayland session one with Xwayland deinstalled – well aware of the fact that this may be fishy.
Some of my statements below refer to both ways of using Wayland (natively or via Xwayland). I use the writing “(X)Wayland” to indicate this.
Plasma start on (X)Wayland
The time for the first startup of a PLasma desktop on (X)Wayland (after a login via SDDM) is rather long (> 10 secs). But do not worry. The next startup times after logouts/relogins are much shorter – if you stick to Xwayland between Plasma sessions and do not switch back to X11 in the meantime.
Behavior of a Plasma desktop on (X)Wayland
Simply: Very good! Much better than with Leap 15.3. You can practically work with the desktop as if your display server were X11/Xorg. There are some small glitches that occur sometimes – like a flicker of the cursor in some applications or a flicker of the background when trying to log out. But there were only a few situations for which I saw a very short flicker effect locally in some browsers and editors. Most often a short flickker happened close to the cursor when I edited this post in the Chromium browser.
But, off topic: The Chromium browser is one of the applications which makes trouble on Leap 15.4 for other reasons. Independent of Gnome, KDE/Plasma, X11 or Wayland it leads to a core-dump whenever it is started. Although afterward it works as expected.
Here some information regarding the running desktop and related processes:
Special applications – flatpak based Blender, KVM with multiple spice screens – on (X)Wayland
First an impression of a fully loaded Plasma desktop stretched over 3 screens. How to arrange the screens in a working order via software settings will be discussed in a forthcoming post.
OpenGL based Plasma effects like “wobbly windows” seem to work as expected on Wayland. I have no tested all, but some major ones.
As you may already have seen on the picture above, glxspheres and a flatpak based Blender 3.4 installation run – with OpenGL support.
Actually, I could work with Blender as I was used to from X11 Plasma sessions. OpenGL based shading of scenes simply worked. I only had to guarantee support for my present Nvidia driver in the flatpak environment.
I was also interested in whether there were any problems with KVM virtualized systems and multiple virtual spice screens. But everything was OK – a KDE desktop on a virtualized Debian/Kali Linux worked flawlessly over multiple spice screen windows on a Plasma Wayland:
There is even a (reduced) nvidia-settings application available for XWayland. It provides at least some information and control over a few central setting regarding the graphics card:
But nvidia-settings on Wayland does not provide options to control the screen order. See the next post in this series for alternatives.
Warnings regarding switching KDE sessions between Xorg and (X)Wayland
When you switch between two KDE/Plasma sessions – one with Xorg and one with Xwayland – you may loose information about the position of opened application windows – both regarding distance to screen borders and regarding the distribution of windows across virtual desktops. In other words: Your last KDE Plasma session will not be restored correctly.
For example, a gkrellm window which you had carefully positioned in an X11 session may be positioned wrongly on (X)Wayland. Especially, if you have multiple screens attached with different resolutions. After a switch to Wayland it appeared with its top far beyond the upper edge of one of my screens with lower resolution than the others.
Note that KDE on Xwayland offers more options for the display of application windows on virtual desktops than Plasma on X11 does: You can select whether a window may appear on 2 or more virtual desktops out of e.g. 8 virtual desktops in total. This is something KDE on Xorg cannot handle – and the application may disappear completely from your desktop when you return to a Xorg session.
Another thing is that some applications (like “kate” or “konsole”) which had opened a series of different files under XWayland will not be shown on the desktop after closing the session under Wayland and opening it again under X11. You have to start these applications manually again. And – more important – the files which you had opened in your Wayland session with kate, kwrite or other applications will not appear in the usual applications’ list of recently opened files .
Other major problems – Switching to console terminals and back to the graphical desktop
- Switching to Conosle terminals while in any Wayland mode by Ctrl-Alt-Fx and back may lead to problems:
The first thing I had to learn is that the graphical desktop for Wayland resides on tty2 and not tty7. So, to get back after e.g. Ctrl-Alt-F1 to the graphical desktop press Ctrl-Alt-F2.
- Another problem is that you should not switch from tty1 to e.g. tty10 and then back to tty2. This lead to a freeze of any keyboard and mouse input.
These is independent of Plasma or Gnome. Both things do NOT happen with X11 and the current Nvidia driver.
Libreoffice 7.4.4, Plasma, Qt5, XWayland – LO terribly slow when scrolling – and a workaround
Before you get too enthusiastic about Wayland: Libreoffice on Plasma with Qt5 on (X)Wayland is almost a No Go. I often use Libreoffice Writer and Libreooffice Draw. Especially with Draw I often have to make sketches of (neural) networks or logistics networks. These networks are complex and the drawings include a lot of layers and connections. When you scroll horizontally or vertically through such drawings you experience a terrible loss of performance on Xwayland and even worse on native Wayland. If there were no workaround this would mean that I could not do my daily work on Xwayland Plasma sessions.
This happens only with Libreoffice on KDE/Plasma – not on Gnome. The reason seems to be a bug of LO with Qt5. See also the comment of a frustrated guy on reddit here.
There seem to be other problems, too. See e.g. here.
The good news is:
I did not see any problems with LO on a Gnome desktop on top of (X)Wayland.
So, those of my readers who like Gnome seemed have a real advantage here. But there is a simple workaround:
The almost perfect operation of Libreoffice on Gnome made me think a bit. Whilst searching on the Internet I stumbled on one of my own blog posts which I had totally forgotten:
What if things have changed – and Libreoffice were working with Wayland on a GTK3 basis?
Workaround for Libreoffice on Plasma for (X)Wayland
- Step 1: Switch off any “hardware acceleration” option in Libreoffice.
- Step 2: Remove the RPM for Qt5-support of LO – “libreoffice-qt5 – Qt5/KDE Frameworks interface for LibreOffice”.
- Step 3: Verify that GTK3-support is still available: Keep or install the RPM “libreoffice-gtk3 – Gtk3 interface for LibreOffice”.
- Step 4: Start Libreoffice on a KDE/Plasma-desktop for (X)Wayland and enjoy a good performance.
And indeed: Afterward the performance of Libreoffice on KDE PLasma on (X)Wayland was as good as on Gnome for Wayland. So, there really sees to be a major bug in either the Qt5 libs or the libreoffice-qt5 package. The latter being more probable.
And how about Gnome and Wayland?
Personally, I have never really liked Gnome and probably never will. But I tested a lotof applications there, too, for roughly one hour. And I can not at all complain: Gnome on top of Wayland works excellent (on a system with a Nvidia card).
Opensuse Leap 15.4 provides a really usable option to work on (X)Wayland – with KDE Plasma or Gnome. There are some glitches on KDE/Plasma. Some local flickering can occur – and you aboslutely should avoid switches to console terminals TTY1, …, TTY6 and TTY10, …TTY12 and back to a Wayland session on TTY2. However, all in all, Plasma or Gnome on (X)Wayland are close to becoming an option for productive work – even on systems with an Nvidia card.
Libreoffice, unfortunately, must be configured to run as a GTK3 application on KDE/Plasma for (X)Wayland. Libreoffice based on Qt5 is buggy and cannot be used with a reasonable performance on (X)Wayland.
In the next post of this series on Leap 15.4 I discuss methods to fix the screen order on systems with multiple attached screens.
We will look at setting options for Plasma and Gnome on X11 and Wayland. But – more interesting – we shall fix the order also for the display manager SDDM.