Tag: wayland (Page 1 of 2)

Well 🙂 This was a short reprieve.
I created a new batch of Plasma5 packages for Slackware-current as KDE-5_20.06. Be sure to read the upgrade instructions very carefully to prevent a total breakage, because this month’s batch is non-standard. More detail about the upgrade steps (like: remove ConsoleKit2 first!) to follow is in the bottom section of this post.

Why a new ‘ktown‘ release so soon after lamenting in my previous post that there would not be a new release for a while?

It is simple and complex at the same time, really.
I was fed up with monthly releases, they felt like a chore I could not get rid of. But the addition of PAM presented opportunities and since I had already declared that no public release should be expected for a while, I suddenly had time to research privately into a nagging problem that was always on the backburner: Wayland sessions in KDE Plasma5 for Slackware. I had this running somewhat, a couple of years ago but it is totally broken for Slackware today.
The Wayland implementation in KDE Plasma5 depends on a session API called “login1” which was originally defined and implemented by systemd and is for the most part (read: the relevant part) implemented in ConsoleKit2 as well. In the current state of software development, unfortunately ConsoleKit2 is blocking a successful Wayland implementation in Slackware; fixing this demands another core change in Slackware (next to PAM).
As if adding PAM was not ‘bad’ enough, we also need the spawn of systemd. Yes, I looked into elogind as a replacement for ConsoleKit2. The elogind sofware – exactly like eudev which we already have in Slackware – is a component of the systemd codebase, which has been isolated, sanitized, with changes away from the name ‘systemd’ and the code has been made fully independent of systemd.
I talked to Patrick about whether he would consider getting rid of ConsoleKit2. For me this was the only motive to continue dabbling with the ‘ktown’ scripts anyway. And he agreed, so I coded some scripting updates, and tested, and failed and failed. That did bad things to my mood, so I checked all my work-in-progress into a git branch and decided to leave it there for a while, simply because I did not have the time anymore, personal life demanded priority.
Some people noticed the new ‘elogind’ git branch, cloned it and continued the experiment. The resulting debugging effort resolved the dead-end I had been facing. And voila, a new package set was the result, with elogind added and thanking ConsoleKit2 for services rendered.
At the same time (thanks Patrick!) Pat Volkerding modified ‘/etc/rc.d/rc.M’ inside the sysvinit-scripts package, and ‘/etc/pam.d/login’ inside the util-linux package of Slackware-current so that they are now compatible with both ConsoleKit2 and elogind:

Thu Jun 18 22:01:29 UTC 2020
a/sysvinit-scripts-2.1-noarch-33.txz: Rebuilt.
  rc.M: add support for elogind. Thanks to alienBOB.
a/util-linux-2.35.2-x86_64-3.txz: Rebuilt.
  /etc/pam.d/login: support pam_elogind.so. Thanks to alienBOB.

followed one day later by the omitted fix to the ‘startx‘ script and a safeguard for those of you who can not read instructions and failed to remove the ConsoleKit2 package:

Fri Jun 19 19:59:04 UTC 2020
a/sysvinit-scripts-2.1-noarch-34.txz: Rebuilt.
  rc.M: check for elogind first so that we can ignore a stale CK2 package.
x/xinit-1.4.1-x86_64-2.txz: Rebuilt.
  When using elogind, start the session on the current console.
  Thanks to alienBOB.

This eased my job considerably. Consider the new ‘ktown’ release as a prep test for inclusion into Slackware.

Elogind and Wayland

Yes, Plasma5 Wayland sessions work now, thanks to the earlier PAM inclusion and now the elogind addition. You can start a Plasma Wayland session via SDDM (runlevel 4) by selecting it in the session drop-down menu.
And you can start a Plasma Wayland session at the console (runlevel 3) by executing the “startkwayland” command.

Note that with elogind as the session/seat manager instead of ConsoleKit2, you’ll see some new behaviour.
A quite obvious change: if you run ‘startx’ or ‘startkwayland’ at the console, you won’t see a VT (virtual terminal) switch. In the past, your console TTY would usually be tty1 but your graphical session would start on tty7 and you would automatically be switched from tty1 to tty7. This is no longer true – the graphical session will re-use your console TTY.
SDDM is still starting on tty7 but only because I make it do so via its configuration file.

Elogind adds a couple of commands which allow you to inspect the nature and status of the logged-in users and their sessions & seats. Check out “man loginctl”. To understand more about the elogind configuration options, read “man logind.conf”.

Running a Wayland session using the proprietary NVIDIA driver is possible – who’d have thought. For a long while, there was an unsurmountable incompatibility between Wayland protocol implementations and the proprietary drivers of Nvidia which historically support only X.Org. But Nvidia added EGLStreams support to their driver a few years back which opened a lot of possibilities.

EGLStreams is one of the two APIs through which a Wayland compositor can talk to a GPU driver. The other API is GBM and this is the API used by all of the Linux kernel’s GPU drivers. All Wayland compositors support GBM, but support for Nvidia’s EGLStreams is limited (momentarily) to the Wayland compositors in KDE and Gnome.

Taken from https://community.kde.org/Plasma/Wayland/Nvidia you should prepare as follows.

• Qt5 >= 5.15 is a requirement, luckily we already have that in Slackware.
• X.Org release >= 1.20 is needed for EGLStreams support in XWayland, which means that all X Window clients which are started in your Wayland session will also have accelerated graphics rendering. Again, Slackware’s version of xorg-server is sufficiently new.
• You need to enable modesetting in the kernel for the Nvidia driver. You can easily check (as root) whether kernel modesetting is enabled by running “cat /sys/module/nvidia_drm/parameters/modeset”. The command’s output should be “Y”.
  If you get a “N”, then you need to add the string “nvidia-drm.modeset=1” to the kernel’s boot commandline e.g. via the ‘append’ parameter in (e)lilo.conf or syslinux.cfg.
  For grub you can add that append-string to the GRUB_CMDLINE_LINUX_DEFAULT definition in the file “/etc/default/grub”, so that when you run “grub-mkconfig -o /boot/grub/grub.cfg” it will be added in every declaration block (thanks to willysr).
• KWin needs to use EGLStreams for accelerated graphics support, as explained above, or else it will default to GBM and you won’t be happy with the  1 FPS refresh rate on your monitor!
  You need to set the environment variable KWIN_DRM_USE_EGL_STREAMS to the value of “1“.
  One way to do this is to create a profile script (e.g. “/etc/profile.d/kwin.sh”). Add the single line:

  export KWIN_DRM_USE_EGL_STREAMS=1

  and make that script executable. Or define this environment variable through any other means that you prefer, for instance if you are not using a bash-compatible shell.

After having played for a bit in a Plasma Wayland session on my desktop computer with a Nvidia card and using their proprietary driver, I can say that there are still some graphical quirks & glitches but I saw no showstoppers.

What else can you expect in KDE-5_20.06?

This June ktown release contains the KDE Frameworks 5.71.0, Plasma 5.19.1 and Applications 20.04.2. All this on top of the Qt 5.15.0 which recently got updated in Slackware-current.

Deps:
I added the package autoconf-archive which was needed to recompile dbus. I added elogind (make sure to ‘removepkg ConsoleKit2’ first!) , and added two recompiled Slackware packages picking up elogind support: dbus and polkit.
I recompiled accountsservice to pick up elogind support as well, and recompiled polkit-qt5, libdbusmenu-qt5, qca-qt5 against the new Qt5 which was upgraded in Slackware since last month’s ‘ktown’ release.
And I recompiled grantlee-qt4 because I had forgotten to do so after the 2018 mass rebuild in Slackware… no-one noticed.

Frameworks:
Frameworks 5.71.0 is an incremental stability release, see: https://kde.org/announcements/kde-frameworks-5.71.0. The Frameworks package which picks up elogind support is: solid.

Plasma:
Plasma 5.19.1 is the second increment of the 5.19 cycle, which means that I skipped the .0 release. See https://kde.org/announcements/plasma-5.19.1 and if you want to read more about the goals for 5.19 you should check out https://kde.org/announcements/plasma-5.19.0 .
There is a new package in Plasma: kwayland-server. The packages which pick up elogind support are: plasma-workspace, powerdevil, kscreenlocker.

Plasma-extra;
In plasma-extra I rebuilt sddm-qt5 to pick up elogind support and added plasma-wayland-protocols as dependency for the new kwayland-server in Plasma.

Applications;
Applications 20.04.2 is an incremental bug fix release, see also https://kde.org/announcements/releases/2020-06-apps-update/

Applications-extra:
For applications-extra, I tried (and failed) to update krita (I got boost related errors) but I did update kmymoney.

Telepathy:
KDE Telepathy is no longer part of my ‘ktown’ distribution of KDE Plasma5.

Where to get KDE Plasma5 for Slackware

NOTE: I will delay the release for a couple of hours to allow everybody to read this post and avoid updating blindly which would break graphical login sessions!

It should be obvious, but these packages will not work on Slackware 14.2. The old (KDE 5_17.11) Plasma5 packages that were still in my ‘ktown’ repository for Slackware 14.2 were removed last month because they were un-maintained and had security issues.

Download the KDE-5_20.06 for Slackware-current from the usual location at https://slackware.nl/alien-kde/current/ or one of its mirrors like http://slackware.uk/people/alien-kde/current/ .

Check out the README file in the root of the repository for detailed installation or upgrade instructions.

BIG FAT WARNING: Read these README instructions carefully! In short:

1. UPGRADE TO THE LATEST slackware-current first.
2. Then, REMOVE the ConsoleKit2 package.
3. Next, install or upgrade the KDE5 package set.
4. Change to directory /usr/share/sddm/scripts/ and move the Xession.new & Xsetup.new files into place (remove the .new extension) after carefully checking that you are not overwriting your own customizations in the Xsession & Xsetup scripts. Note: because “slackpkg new-config” only looks inside the /etc/ directory it will miss the two scripts in /usr/share/sddm/scripts/.
   You’ll still have to manually check /etc/ for some critical *.new files that need to be put into place if you are not using slackpkg (which does this *.new check at the end of its run).
5. Finally, REBOOT.

Development of Plasma5 is tracked in git: https://git.slackware.nl/ktown/ and this month’s development takes place in the ‘elogind‘ branch..

A new Plasma5 Live ISO will be available soon at https://slackware.nl/slackware-live/latest/ (rsync://slackware.nl/mirrors/slackware-live/latest/) with user/pass being “live/live” as always.

Have fun! Eric