Last year August 2016 I experimented with Wayland, the alternative to the X Window system. My goal was to see if it is possible to run a Plasma5 desktop session on a Wayland compositor instead of using X.Org.
There was one big showstopper at the time. Kwin_wayland has a dependency on the ‘logind’ DBus API and at that time last year, this API was only provided by systemd-logind. Luckily, someone treated the logind component of systemd similarly to its udev component. Where Slackware already uses “eudev” which is a standalone udev source extracted from the systemd source, there’s also “elogind” which is the standalone logind sourcecode, extracted from systemd sourcecode. With some difficulty I managed to create a Slackware package for elogind and everything compiled. I just could not get a working Wayland session.
As it turns out today, that failure to get Wayland working was an omission on my side… more on that later.
Shortly after, IBM told me I would lose my job, I found another job at ASML and life was hectic and remained so. I never got another opportunity to research the root cause of my Wayland failure.
Now that I have a week off, I decided to revisit the old Wayland disaster. After last year’s frustration over the need for elogind, I talked to the ConsoleKit2 developer and to the KWin developer, to see if CK2 could be extended with the required logind DBus API (parts of that API were already incorporated) and to get CK2 accepted as an alternative to systemd-logind on systems that don’t ship with systemd. Both wishes were fulfilled this summer, so I could drop elogind from my package set. I still needed to recompile / upgrade some other packages to add wayland support to them, but the fact is: Slackware does not need PAM or systemd to get Wayland working.
Therefore, my KDE 5_17.10_testing repository contains mostly what you already know and love: KDE Frameworks 5.39.0, Plasma 5.11.0 and Applications 17.08.2. All based on Qt 5.9.2. Just with 17 differences in the package list.
Why does Wayland work now, while it did not last year?
Well, that was entirely my perception of things. Probably would have worked last year as well, if only I had recognized the signs. Last year, and yesterday as well, all the puzzle pieces seemed to be OK, but their integration failed. The signs (using strace and gdb to find out why the Wayland session would not start) were telling me that KWin was trying to find a logind provider on the DBus and no-one was answering. It took a sudden insight this morning, the realization that there is one difference between Slackware and all those other distros. And I have been using a workaround for ages, and I just did not think about that.
When you login on a system running PAM, a login session is registered on the bus using either ConsoleKit2 or systemd-logind. Our PAM-free Slackware needs an additional “ck-launch-session” command in front of the “dbus-launch” command to connect a new ConsoleKit2 session to the bus and let KWin find it there… when I fixed that, my Wayland session just sprang into existence!
How to start a Plasma5 Wayland session
- Runlevel 3 (console): run the ‘startkwayland‘ command as your regular user.
- Runlevel 4 (SDDM): select “Plasma (Wayland)” from the session dropdown and then proceed to login.
Of course… nothing works 100% the first time. So what have I ran into? Note that I have been running Wayland for a couple of hours only, so I can say little about its stability.
- Dropbox does not start, unless you ‘unset’ the QT_QPA_PLATFORM variable first. This is caused by the fact that Dropbox uses its own internal Qt5 libraries and it does not come with Wayland support.
- Gnome-keyring does not start for some reason, so you can not auto-login to skypeforlinux for instance
- HP-tray was eating 100% CPU at some point and draining my battery. I had to kill the process.
- Yakuake does not work (I know, it is not part of my ‘ktown’ package set)
- Unlike an X.Org session, the Wayland session does not require an additional <Ctrl> keypress to switch to a virtual console. Therefore, when I wanted to invoke krunner with <Alt><F2>, instead I was switched to the second virtual console, tty2. Upon returning to the Wayland session (which was running on VT4 as opposed to VT7 for X.Org) the krunner window was waiting for me. Apparently both the OS and KWin process the <Alt><FunctionKey> combos.
A note about NVIDIA: I know that there are issues between the binary driver and Wayland. Please do your research if you use the binary Nvidia blob. My laptop has an Intel GPU which runs on the open source kernel driver, and has no issues.
Note: check out the KDE page which documents the Wayland issues: https://community.kde.org/Plasma/Wayland_Showstoppers
What’s needed to make Plasma5 work with Wayland in Slackware
We need Wayland support in the core of the OS as well as in the dependencies for Plasma5. Also we need a version of ConsoleKit2 that works with Kwin_wayland. Which means:
- add a wayland-protocols package (wayland is no longer sufficient)
- add an upgraded ConsoleKit2
- recompile Slackware’s mesa using a slightly modified SlackBuild script (change the package tag from ‘alien’ to ‘wayland’)
- write a xorg-server.SlackBuild script based on the code in the x11.SlackBuild framework of Slackware, and recompile xorg-server with that script (change the package tag from ‘alien’ to ‘wayland’)
- recompile libxkbcommon (change the package tag from ‘alien’ to ‘wayland’)
- recompile qt5 (change the package tag from ‘alien’ to ‘wayland’)
With the ‘deps’ taken care of, proceed to Frameworks:
- recompile kwayland and plasma-framework (change the package tag from ‘alien’ to ‘wayland’)
And finally the Plasma packages that use Wayland in some way or other:
- recompile kinfocenter, kscreenlocker, kwayland-integration, libkscreen2, plasma-desktop, plasma-integration, plasma-workspace, powerdevil and kwin (change the package tag from ‘alien’ to ‘wayland’)
You will have noticed that the packages I tagged with ‘wayland‘ instead of the usual ‘alien‘ tag, are the ones that picked up Wayland support as compared with their originals. This makes it quite easy for you to switch back to the original packages (mesa and xorg-server in Slackware and the other 13 in ‘ktown’) if you are done with your testing. The remaining ‘alien’ packages (wayland-protocols and ConsoleKit2) can be kept without penalty.
A final note about this updated xorg-server package. My version of that package is a 4-into-1 package; it contains xorg-server-xephyr, xorg-server-xnest and xorg-server-xvfb as well. If you decide to remove the testing packages and want to go back to Slackware’s non-wayland version of xorg-server, you must also re-install the other three xorg-server-x* packages.
Installing or upgrading Frameworks, Plasma and Applications
Please use the README file in the ‘latest’ repository for the installation & upgrade instructions. I reserved the README.testing in the ‘testing’ repository to highlight the differences between the two repositories.
Where to get these ‘testing’ packages for Plasma Wayland
Package download locations are listed below (you will find the sources in ./source/5/ and packages in /current/testing/ subdirectory). Only “bear” has the packages for now, the mirrors should follow within 24 hours. If you are interested in the development of KDE 5 for Slackware, you can peek at my git repository too. There is now only one source tree to create both ‘latest‘ and ‘testing‘ repositories.
- http://bear.alienbase.nl/mirrors/alien-kde/ (my own mirror), rsync URI is rsync://bear.alienbase.nl/mirrors/alien-kde/.
- http://repo.ukdw.ac.id/alien-kde/ (willysr’s Indonesian mirror), rsync URI: rsync://repo.ukdw.ac.id/alien-kde/
- http://ftp.lip6.fr/pub/linux/distributions/slackware/people/alien-kde/ French fast mirror thanks to Tonus.
- http://slackware.uk/people/alien-kde/ (fast UK based mirror, run by Darren Austin), rsync URI: rsync://slackware.uk/people/alien-kde/
Live ISO of PLASMA5
There will probably not be a Plasma5 Live ISO image based on the ‘testing’ repository with working Wayland support. My ‘bear’ server just does not have the disk space to host an additional 4 GB ISO file. Nevertheless, you can tranfer the existing Plasma5 Live ISO to USB stick, change the ‘latest‘ ktown repository to ‘testing‘ in the slackpkg+ configuration file “/etc/slackpkg/slackpkgplus.conf” and run “slackpkg update ; slackpkg install ktown ; slackpkg upgrade ktown” to get the 4 new packages and upgrade the 13 other packages. If you do not use slackpkg with slackpkg+ then simply look at the short list of packages to be installed or upgraded, higher up on this page.
Have fun! Eric