"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!

Reason for the blog

I'm changing KDE startup/shutdown a lot, whilst I aim to keep everything working exactly as before, please test this part thoroughly and report if you see any issues in the 5.15 cycle.

What is ksmserver?

In theory ksmserver is an X session manager.
An X session manager is responsible for saving/restoring your session when you log out and in
(and subsessions if you use activities) as well as prompting all your applications if it's safe to log out.

Currently this is one of the most important processes of the plasma session. Killing this process will immediately end the session.

As it runs all session it's a bit of a dumping ground for:
- handling all autostart (including plasmashell etc)
- running shutdown scripts
- screensaver
- some global shortcuts about session management
- spawning the logout prompts
- invoking the actual shutdown

Why change it?

As ksmserver handles startup our wayland session depends on X (or rather Xwayland), this is slower as we have to spawn it on startup, as well as being problematic for alternative devices where Xwayland may not be a useful option.

Also if we come up with a new session manager protocol that works well with wayland, we will need to replace just the session manager part.

Equally we have attempts to replace startup with for example, systemd units (and yes, there'd be a fallback) where we still want a working session manager.

In addition, some of the code isn't in the best state. It dates back to the 90s, without really having an active maintainer. There's been some significant changes to the way linux desktops work since that time. There's a lot to be cleaned up.

The plan

The golden rule is to refactor not rewrite. There have been numerous attempts at redoing startup, all good tech demos, but none are usable for production as they don't pay attention to matching with the current state and intricate startup hooks, something we need when we're talking about enterprise deployment who will have customisations.

The end goal is for KSMServer to be just an xsessionmanager. Allowing wayland-compatiable competitors to come alongside or potentially replace it down the line.

Startup and Shutdown will become multiple independent binaries (unix philosophy style) allowing them to be individually replaced all tied together with DBus activation. They will also be refactored to be considerably more readable.

Current state

There's been an internal refactor, which has been merged in master, the next step is to split into different processes once we've had feedback on the current work.

June has been a busy month in KWin, with me working on fixing remaining Wayland functionality and upcoming legend Vlad Zagorodniy working on polishing and cleaning up all the effects.

In this blog I'll talk about the more interesting bits of kwin work that I did during June.

Fractional Scaling

A requested feature is to allow fractional scaling for QHD monitors which are roughly 1.5 times the resolution of standard monitors, but not the full 4k.

The wayland scale system is based around integers, but because the scaling is based around a normalised co-ordinate system, the compositor can show a display at a scale of 1.5 whilst clients are rendering for a 2x display with no changes in the client.

Patchset consists of XdgOutput support in both kwin and Qt so that windows that position themselves (such as xwayland clients, or plasmashell) can know the correct logical size of the screen and then relevant changes in kwin/kscreen to implement the extra fractional part.

Unfortunately as this requires a change in Qt to function properly. this won't be available in our UI until Plasma depends on the Qt version that contains this support, probably around March 2019. Stupid desktop Linux.

Cursor Scaling

On the topic of scaling, I merged support for making sure that the cursor is the physical size the user selected regardless of the resolution of the monitor it happens to be on or the scale of the client that supplied it. Particularly useful for a multi-monitor setup where blindly using a pixel size doesn't cut it.

XdgWmBase

The protocol for clients to register toplevels and popups to the window manager has gone through multiple stages, wl_shell, XDGShellV5, XdgShellV6 now settling on the finally stable protocol, Xdg WM Base. Having this finally stable is a hugely signifiant point in the road to wayland.

Previously we were lagging behind other desktops in shell protocol support, but KWin 5.14 will have support for XDG WM Base ahead of the toolkit support coming in Qt 5.12 / next GTK.

GTK decorations

GTK gained server side decoration support in 3.22, however, the implementation needed some work. It correctly removed it's own decorations under KWin but failed to inform KWin, which didn't want to add a "second" titlebar, leaving it in an even worse state than before.

I submitted a patch for GTK rectifiying all the issues and that was all merged pretty swiftly.

Misc

KWin also gained support to show different mouse cursors for resizing the left edge of a window or the right edge of a window. Useful for telling which window will be resized in the case of touching windows.

Startup is one of the rougher aspects of the Plasma experience and therefore something we've put some time into fixing

Why is startup slow?

The primary reason for Plasma startup being slow is simply that it does a lot of things, including:

• Session restore
• Config migration
• Setting keyboard layouts
• Most esoterically, making sure your colour scheme gets synced to the xrdb database, so that loading xfig or dia or any other pre-Qt/GTK1 application still has the correct colours in your Plasma session

Too many to list. This means it's easily a whole second or more before we even start loading plasmashell, one of the more time consuming parts of startup.
This slow load gets exaggerated by us not removing the splash screen till everything is actually properly loaded.

However, it's still an area we can improve.

About startup

Startup consists of mulitple components invoked at 3 different levels.

• Kcminit
  Config modules (kcms) typically update a system when the user applies the settings, however as we need to restore settings there is an optional hook called on startup for various modules.
• KDE Daemons (kded)
  Evolving from the more static nature above may services require running in the background waiting for external events. Some modules are loaded on demand, others are loaded explicitly during startup.
• Autostarted applications
  Meaning launcing core applications such as plasmashell/krunner as well as other applications a user might have selected; such as nextcloud or kgpg
• User shell scripts
  For anything else

These effectively all have their loading invoked at 3 different levels; as defined in the relevant kcminit/kded/autostart .desktop files. Note these may be shipped as core plasma, but can also include completely 3rd party items.

• Before plasmashell and other core autostart services
• Before user applications are restored / autoloaded
• After everything is restored and

A slightly more detailed version can be seen here.

Profiling

The most important part of any speed work is correctly analysing it.
systemd-bootchart is nearly perfect for this job, but it's filled with a lot of system noise.

I've made a fork of systemd-bootchart that only tracks processes owned by that user on github.
To use put the following line into:
/etc/X11/Xsession.d/00-bootchart

/usr/lib/systemd/systemd-bootchart -o /tmp -r &

To profile wayland sessions, mod the SDDM config wayland SessionCommand option.

After 20 seconds an SVG will be placed in /tmp.

An example

Below shows the boot process of my personal machine. The important part to track is when ksplashqml gets destroyed, that signifies that boot is complete. In my case this happens after 4.5 seconds.

Just some of the many fixes

There have been and continue to be lots of tiny changes around the code. Mostly using the awesome tool hotspot here are just a few of the more significant and interesting ones.

A mysterious gap of nothingness

This stupid bug was caused by ksmserver blocking whilst it completed launching phase 1 of kded daemons before it continued onto loading the next section.
Problem is plasmashell and other GUI apps loaded in phase0 first task is to register with the X session manager, ksmserver. End result is we lockup in X code till
ksmserver is done. Solved by a logic rewrite.

Multiple starts of the same daemon

This is the result of the following code in a bunch of processes all started at once.

if (! serviceExistsOnDBus) {
startExecutable(...)
}

Whilst the daemon did handle this case correctly and the false starts aborted, it's still a lot of time spend linking a process we don't want.
Solution in this case was to port to DBus activation which is designed for this exact case.

Shortcuts writing on load

When profiling kglobalaccel5 we found it spent a lot of time writing entries on boot, which is a clear sign of something being wrong. The cause was quite complex. Powerdevil would report that the user visible name of the executable (kded) was "Powerdevil". KScreen would load and report that the username of the executable (also kded) was "kded" this would cause the shortcut daemon to think locales had changed and forcibly reload and save everything.

Summary

Startup is an area that is being improved and we have tonnes of ideas left of things to do, but because it's dealing with unpredictable 3rd parties it's an area which requires 90% reading and 10% coding.

If you do have an excessively long boot time, please do try creating a boot chart as above, it will really help start to narrow down where we have problem. I hope to see some detailed reports on bugzilla soon.

KRunner, the framework, is the backend behind the 'krunner' UI, as well as being used for search operations within the Plasma shell. Backends (or 'runners') are written as plugins, which can come from a range of sources and loaded by both the plasmashell and krunner process.

This works fine for simple tasks like calculators, dictionaries and listing applications. However, if we want to search through data that's available in an already running application, this approach isn't ideal.

What's changing

In addition to the current plugin structure, runners can have their results fetched from another process via DBus.

To work, apps supply a .desktop file with the DBus service name of a search provider. The apps then implements a couple of DBus methods to return a list of matches for a given search query, and another method called when a match is invoked. Depending on the situation, you might want to make this DBus-activatable, or just silently do nothing if the service is not running.

Example of a query being performed:

Results are presented identically.

Benefits:

Reduce code re-implementations

The original motivation for writing this was plasma-browser-integration writing a runner. Kai ended up writing both a DBus API on the client, and a runner to read from it. A common standard cuts that in half for any future apps wanting runners.

Memory saving

Instead of data being in 3 places: the app with the data, plasma shell and krunner, data is only stored in one place and then fetched by the two UIs.

Robustness

Plasma shell is a very core process. We want that to stay alive even if the included plugins fail. One of our more problematic runners was moved out of process to solve this in Plasma/5.11

Portability

By not being linked inside the same binary, we solve a lot of portability issues.

* I can make runners in python (example) or potentially any other language with no extra dependencies

* We'll be able to handle the ineviatible Qt6 changeover in a few years without runners having to all be ported at the same time.

This was a big problem for KTp, which had the main USP of having tight Plasma integration. We caused a big problem for ourselves resulting in a rushed port.

* It's a step towards next gen where more apps and services are sandboxed.

Conclusion

Hopefully this will improve Plasma and make it easier to write runners.

I hope to see runner support to kde-connect and search active konversation tabs. Personally, I'm already using the python support for custom code to talk to my home-automation server which had a python lib.

If this has inspired you to write a runner and documentation is unclear, ping me (d_ed) on #plasma.

Marco Martin recently posted about some of the improvements in krunner, today I want to show some of the effort into navigating the Plasma panels.

This video shows a user navigating the plasma panel using voice and keyboard. A shortcut focusses the panel, and then one can use tab and cursor keys as normal. In future we will improve our key-focus visual indicators, and allow for richer interaction.

What makes Plasma different to existing apps

Plasma in general has been a sore point with regards to accessibility as it doesn't follow some of the exact same concepts as a traditional toolkit. Some of these convention breakages are by design, in krunner you wouldn't want to have to tab to a list of results in order to navigate results with the cursor keys. Unfortunately these changes, if done non-optimally, really conflict with core concepts of focus and screen reader parsing. On top of that, we have the issues of an emerging toolkit, which needs that extra push to get right.

Why is this work useful?

Blind people aside, the work here has multiple other advantages.

We need better keyboard navigation, regardless. You often hear people say they prefer console apps; it's not because they're inherently better, but because being "handicapped" forces them to have good keyboard handling. We should be matching or beating that.

Also, approaching a large code base from a completely different angle has helped to tidy up some complex code that has built up over the years. Kickoff key handling is now not only better but the code is 2/3 the size.

---

SDDM is a Qt based Display Manager used by multiple desktops, but most importantly (certainly for the PlanetKDE crowd), KDE.

After a year of seemingly little activity, I've released SDDM v0.15.0
It is mostly a bugfix release with important changes, but nothing to get particularly excited about.

For full release notes please see: https://github.com/sddm/sddm/wiki/0.15.0-Release-Announcement

Now this is out, I shall be merge a huge queue of pending larger changes - hopefully we shall see 0.16 in only a few months.

We want:

Legacy apps at the same physical as modern apps that support high DPI

Apps and window decoration to work across multiple screens at different DPI

Consistent mouse speed and input across monitors of different DPI

What we want to see:

What we need to render

How it works:

In order to have a normalised co-ordinate system between monitors and to support apps that can't scale themselves the system is defined as follows:

* KWin pretends all monitors are ~96dpi and handles all communication and input co-ordinates as such. Final output is then scaled up if applicable

* Clients which support high DPI, when relevant, will provide a buffer (the picture of their contents) which is twice the resolution of their window size.

This covers all the different scenarios:

If we have a 1x window on a 2x screen, the compositor will draw the window twice the size.

If we have a 2x window on a 1x screen, the window contents will be drawn implicitly downsized.

If we have a 2x window on a 2x screen, the window will be drawn twice the size, but because it's at twice the resolution, we end up painting the contents at the native resolution.

Clients without scaling now work as intended, I can use ardour or xfig on my high DPI screen and can read and interact with it normally (albeit obviously at standard resolution)

The mouse even moves at a consistent speed across monitors and even if you had two touch screens at different DPI showing the same content, both will work perfectly.

The changes to kwin were therefore really small, and mostly was not about implementing features but more about removing an assumed coupling between a texture size and the rendered size.

FAQ

When?

The code to do all of this is in Plasma 5.10 as a hidden feature whilst we get more testing with everything except a UI to configure it. This is ready to land for 5.11 An extra problem is that Qt < 5.9 has a bug if the screen scale changes dynamically.

What's left?

Using this technique means everything is at the right size, but some adjustments are needed to make sure everything appears at native DPI not normal DPI. This is something being fixed over time.

What about fractional scaling?

The wayland protocol specifies a scaling in integers. We can't really go against the protocol. However, there's absolutely nothing against kwin scaling to a different amount to the protocol. It's something we can expand on later.