"6.0" is a word that brings a lot of excitement but also a lot of aprehension and for good reason. The reason our .0 releases sometimes struggle to match the quality isn't due to changes in the underlying libraries changing but how much we have to port away from the things that we've deprecated internally and have put off porting to.

Too many changes in one release becomes overwhelming and bugs creep in without time to get address them.

We want to be proactive in avoiding that.

At a recent Plasma sprint, we went through some of our bigger targets that we want to finish completely porting away from in time for the 6.0 release that we can actively start doing within the 5.x series where we can do things more gradually and inrecementally.

I've listed two big topics below.

DataEngines

History

DataEngines were a piece of tech from the KDE4 era. Effectively the idea was to provide an abstract mechanism to expose arbitrary data or plugins to a scriptable format usable by various language bindings. A valid task at the time, but Qt5 provided a much more efficent mechanism to do this capitalising on the metaobject system and models

DataEngines mostly form a now unnecessary layer of indirection that makes QML code hard to parse and suboptimal to run. They also are Plasma specific, which doesn't help other QML consumers of the same data.

We kept with them for Plasma 5 as there's some valid, perfectly working code exposed through them, and have been slowly porting away.

Task

The task isn't to port all existing DataEngines. Some already have replacements under different names, some aren't widely used.

We want to find all existing applets that use DataEngines and make sure there are modern new QML bindings we can port the repsective applets to.

A list of tasks can be found:
https://phabricator.kde.org/T13315

System settings modules

History

Systemsettings is powered by a multitude of KDE Configuration Modules (KCMs) each one is a standalone plugin. There are nearly 100 modules, and with dated code stretching back over 20 years.

KDE, plasma especially is on the turning point between two toolkits. Some things are written in QWidgets and other things use the newer QtQuick. We try and hide this from the user; everything should of course look seamless. Implementation details shouldn't affect the UI.

We've been slowly porting our system settings modules, and whilst some were rocky at first, the later results are looking really nice and really polished, able to make use of emerging new patterns in our Kirigami toolkit.

Mixing two toolkits in the same process leads to a lot of complications that leak into the UI as well as overhead. We want to make it an objective to see if we can port everything to lead to an overall simpler stack.

Task

The overall task is to find KCMs that haven't been ported yet and make the appropriate changes.

However, this isn't just a goal of blindly porting.

We want to take a step back, really polishing the UX, tidying the code to have a good logic vs UI split and revsit some modules that haven't been touched in a long time, putting effort into our underlying frameworks to make sure we have everything ready on the QtQuick side to do so.

A list of KCMs and their porting status can be found:
https://phabricator.kde.org/tag/plasma_kcm_redesign/

Getting involved

The best way to get involved is to comment on the relevant phabricator ticket. Or swing by #plasma on IRC and let people know what you want to work on and we'll help you get started.
Some of the systemsettings modules have mockups from the VDG and we want to keep them in the loop.

Note: If you are visiting from the future please refer to the wiki here which will be more up-to-date than this blog post.

---

I recently switched to running wayland fulltime on all my machines, including my Nvidia box. It was good that I did as it seems Qt regressed, fortunately I was able to fix it just in time for the final Qt LTS.

I've also updated the wiki with the steps needed to run nvidia wayland whilst I had the information fresh.

Steps

Pre-requisites

You need a very up-to-date Qt. Make sure you have >= Qt5.15.0 or 4bd13402f0293e85b8dfdf92254e250ac28094c7 cherry-picked.

Mode setting

Check our driver is running in modesettings mode

cat /sys/module/nvidia_drm/parameters/modeset

It should print "Y"

If not, modify your kernel command line and add the line nvidia-drm.modeset=1. Search for "kernel parameters" in your distribution's documentation. Though https://wiki.archlinux.org/index.php/Kernel_parameters is typically a good guide for any distro.

Tell kwin to run with EGLStreams.

You should set the environment variable "KWIN_DRM_USE_EGL_STREAMS=1"

The easiest place is to add a file /etc/profile.d/kwin.sh with the line
export KWIN_DRM_USE_EGL_STREAMS=1

Verify this is working with the command line tool env after rebooting.

Login

Select "Plasma (wayland)" from your login manager
Enjoy your beautiful super-fast accelerated wayland desktop!

That's a lot of steps!

Obviously this number of manual steps is unnacceptable and I hope to reduce this over the next Plasma cycle.

With the user telemetry we get from Plasma users, we know a sizable amount of X11 users run the proprietory nvidia wayland driver. Ultimately user experience comes first above all else, so it is important.

Clearing up some facts on Nvidia and wayland

I read a lot of misinformation that on the wayland nvidia situation on the social medias. I'll try and clarfify some bits.

• You cannot say "Nvidia doesn't support wayland". This doesn't make any sense. There's no relevant part of wayland for it to support or not support.

• You can say "Nvidia doesn't support GBM" . A system for passing buffers (window contents) between places. Despite the name "Generic" Buffer Manager, GBM is very closely tied to Mesa. Mesa is the base of effectively all the open source Linux drivers.

---

• You cannot say "Nvidia doesn't follow /the/ standard". There are a few. EGLStreams actually is a fully defined open standard defined in Khronos, which is as much of a core extension as possible. It's used by multiple vendors, albeit mostly horrible Mali chips

• You can say it would be better if there was just one magic implementation that compositors and toolkits had to support. Maybe Vulkan (or more specifically WSI) will fix it 🙂

---

• You cannot say that the experience of using wayland apps is worse on wayland. Practically it's just as fast, accelerated with all the shiny effects.

• You can say that the experience of using GL X11 apps on wayland is worse. As XWayland doesn't have EGLStream support data gets copied the slow way. If you're playing an X game or doing some Blender work this is noticable.

---

• You cannot say that KDE devs won't fix it. As this post starts with me literally fixing a toolkit when it came up!

• You can say that Nvidia wayland experience has fewer testers. Though like all things wayland this is something you can help with! Get involved, file bugs, come join us on #kwin on Freenode. Start your kwin wayland hacking journey!