Screenlocker architecture in Plasma Next

The 14.04 release of Unity unfortunately shipped with a few security vulnerabilities in the newly introduced screenlocker. As we will also ship a reworked screenlocker in Plasma Next I started to do another code audit, add more unit tests and try to make the code easier to understand and maintain. Furthermore I think it’s a good reason to explain how screenlockers work in general on X11 (and why it is easy to introduce security vulnerabilities) and the screenlocker in Plasma Next in particular. To make one thing clear: this post is not meant to shame Ubuntu for the issues. Some of these whoopies would have been possible in Plasma, too, and that’s the reason why I looked at the code again in more detail. On the other hand I think that our screenlocker in Plasma Next could be a solution for Unity’s use cases and I would appreciate if Ubuntu would adpot our solution.

What a screenlocker should protect

Before looking at how it works in X11, I shortly want to discuss what a screenlocker can protect and what is out of scope for a screenlocker. In general there are two tasks for a screenlocker:

  • Blocking input devices, so that an attacker cannot interact with the running session
  • Blanking the screen to prevent private information being leaked

The lock is hold till an authorization is provided (e.g. password). I’ll discuss in more detail what these authorizations are in the case of Plasma.

There are a few things the screenlocker cannot protect against:

  • Evil software already running under the user’s account
  • Attackers having access to a tty running under the same user

To explain the first problem we must remember that X11 is very bad from a security point of view. This adds a general limitation to what can be protected. Getting a key logger with X11 is extremely trivial, there are easier ways to get the password than to try to attack the locker.

The second problem goes in the same direction: if someone has access to a tty, he can install an X11 key logger. It will not get the password, but still it’s a huge problem. Also the attacker could reconfigure the locker or run a debugger on the lock process to just end the locker. Some of these problems can be mitigated by the distribution through hardening (e.g. SELinux).

I plan to harden the system against these two problems in a future release. Though given the general problems of X11 it will never be possible to completely solve these two problems on X11.

How screenlockers work in X11

X11 doesn’t really know the concept of a screenlocker. Thus one needs to use the concepts of X11 to try to get something like a screenlocker. The main features are grabbing the keyboard and grabbing the pointer. What’s important to know about these two X11 features is that only one X Client is allowed to grab the keyboard and pointer. If the keyboard or pointer is already grabbed the lock cannot be established. For example if a (context) menu is open the screen cannot be locked or if Present Windows is active.

Having the keyboard and pointer grabbed are essential to fulfill the first task of the screenlocker. This also shows why it’s so difficult to get a locker right. As soon as the process grabbing the keyboard goes away the lock is released. As soon as that happens the screen is unlocked. Thus there is an easy scenario to attack a screenlocker: get the lock process to crash and restart and try to grab the keyboard before the screenlocker is able to re-install the grab.

This is the problem Unity run in and to be honest we also almost run into this issue in the past. Thus a screenlocker implementation must be able to hold the keyboard grab during a crash. A lock file might not be sufficient. I will explain later how we made the screenlocker in Plasma crash resistant, so that the session will never be unlocked.

The second task is blanking the screen. This is done by creating a lock window and raise it on top of all windows and ensure that the lock window is always on top of all windows. Given the description one can notice that this is kind of a fragile process. Assume one has two processes trying to be on top of each other: they will constantly try to raise on top of the other. Something I once experienced by having the screen locked during session startup resulting in a race between login and lock screen. Again Wayland will improve the situation as the compositor (in our case KWin) will be aware of the screenlocker and will ensure the restrictions.

Screenlocker architecture in Plasma Next

The architecture for locking screens got simplified in Plasma Next. Support for screen savers got completely removed (fear not: we have plans for replacement, probably not in Plasma Next, but in a future release) and that helped a lot to trim down the architecture.

In Plasma Next the locking consists of three interacting processes:

  • KSLD in KSMServer
  • kscreenlocker_greet (greeter)
  • kcheckpass

While this might sound complex to have three processes it’s following the unix philosophy of one tool, one task. So let’s look at what the processes do.

KSLD

KSLD (for KScreenLocker Daemon) is a library used by KSMServer. KSMServer is our session server which gets started during session startup and keeps the session alive. If it crashes the session dies with it and you are returned to the login screen. KSLD is the main component of the screenlocker: it listens to the activation signal (e.g. global shortcut or logind), installs the X11 lock, blanks the screen and waits for the authorization to unlock the screen again.

At the moment KSLD has three authorization mechanisms:

  • User configurable grace time: any user input during the grace time interval immediately unlocks the screen
  • logind: listens to Unlock signal on the session’s object
  • greeter process: exits with exit code 0

The most complex authorization mechanism is the greeter. For that the greeter process needs to be started and is monitored by KSLD. If the greeter process crashes the lock is kept and the greeter process is started again. The authorization to unlock is provided by the exit code of the process. If it exits with 0 the screen gets unlocked, with any other code the greeter gets started again.

Of course we need to show the greeter – so far the screen is blanked and no window is allowed to go above the blanked window. To achieve this the greeter can set a special window property on its windows and ksld will raise those above the locker and forward input events to this X client.

Security note: this cannot protect against malicious software already running on the user’s session. A malicious software could set the same property and thus read the input events. I intend to change this for a future release to have a socket communication between ksld and the greeter to pass window information and input events. Obviously it’s a good idea to use the Wayland protocol for this task – also on X11.

kscreenlocker_greet

The second process in our architecture is kscreenlocker_greet which got partially already explained in the previous section. In Plasma it’s responsible for rendering the unlock screen interface and the session switching interface. The user interface is implemented using QML allowing us to easily adopt to new use cases – e.g. the unlock screen in Plasma Active is just a different QML package.

For future releases we have some ideas to improve the experience by allowing to run our normal wallpaper plugins (bringing back animations) and allowing some selected plasmoids to go on the lock screen. Of course we need to white list the plasmoids which are allowed to go on the lock screen to not expose private information or even allow to start processes. It would be a bad idea to add a terminal emulator as a plasmoid.

kcheckpass

As mentioned our architecture is following the “do one thing, do it right” approach and the task of the greeter is only to provide the user interface. It does not perform any password verification. For that it uses kcheckpass, which is a small terminal application to verify a provided user password. If the user clicks the unlock in the greeter kcheckpass is invoked and the password is passed to kcheckpass through a binary socket protocol. Kcheckpass communicates with PAM to verify the password and can pass back an authentication success, authentication error or further information for PAM modules needing further interaction like a fingerprint reader. These messages and authentication failure are passed back to the greeter ui. If the authentication is successful the greeter exits with exit code 0.

This concludes the look on the various components. I would encourage all readers to try to break the architecture before we have a release. I’m quite confident that the architecture is secure and also more secure than what we had in 4.x.

XScreenSaver

Last but not least I want to share some thoughts on XScreenSaver. Whenever an issue arises like the ones in Unity we can hear people claiming one should use XScreenSaver because it’s way more secure. Now personally I don’t believe in silver bullets – especially not if it comes to security. In the beginning of this long blog post I stated two tasks a screenlocker needs to provide and XScreenSaver can fail with the second: the screen content can be exposed. Consider for example the linked screenshot. For a screen saver of the last millennium this was a suitable solution, but not for an implementation where we want to focus on security.

As we can read in the section On Toolkit Dialogs the security of XScreenSaver is based on the fact of not using a GUI toolkit. While the argumentation sounds good, it fails to see the need of today’s desktop environments. Providing an unlock dialog which can be styled with XLib might be a solution for the 90ies but not in a world where we want to provide an awesome user experience. Today users also expect the current time, battery state and many more information on the lock screen. We need to provide accessibility features which is not possible in XScreenSaver. We need to use proper idle mechanism shared with other applications. We need DBus integration, inhibition (XScreenSaver doesn’t support this!) and logind integration. Not using toolkits also means to have to fix bugs which the toolkit would solve for you, this is again increasing the risk of broken code and crashes in the daemon. Just consider this piece of code I found in XScreenSaver:

/* It turns out that if we do setlocale (LC_ALL, "") here, people
    running in Japanese locales get font craziness on the password
    dialog, presumably because it is displaying Japanese characters
    in a non-Japanese font.  However, if we don't call setlocale()
    at all, then XLookupString() never returns multi-byte UTF-8
    characters when people type non-Latin1 characters on the
    keyboard.
   
    The current theory (and at this point, I'm really guessing!) is
    that using LC_CTYPE instead of LC_ALL will make XLookupString()
    behave usefully, without having the side-effect of screwing up
    the fonts on the unlock dialog.
   
    See https://bugs.launchpad.net/ubuntu/+source/xscreensaver/+bug/671923
    from comment #20 onward.
   
      -- jwz, 24-Sep-2011
*/

Now if you consider the architecture I explained the “problem” of the toolkit doesn’t matter at all. We are running an interpreted (QML) language which heavily uses OpenGL without introducing any security risks by using separate processes. If the application which holds the lock (and also heavily uses Qt) crashes the complete session goes down. In turn I think that the argumentation provided by the XScreenSaver maintainer doesn’t hold. Even more I haven’t seen anything about crash resistance like we have in Plasma to have the session getting killed if the lock process crashes. I’m not saying that this doesn’t exist (the code base is very large and I haven’t done a full audit) but I haven’t seen anything in the very prominent documentation about why it’s better.

Of course one could ask why we don’t work on XScreenSaver to improve it and make it work for our use cases. I don’t think that this is possible and at least I would not even try to. It’s quite clear that code using toolkits is not wanted. I also doubt that the needs of desktop environments like Plasma, GNOME Shell or Unity are understood at all. Let me quote the FAQ:

KDE suffers from the same brain damage as GNOME, above.

The only sensible (and secure) way to use a screen saver under KDE is to turn off KDE’s built-in screen saver, and use xscreensaver instead.

With that attitude I think it’s quite obvious why at least I see zero chances to use XScreenSaver in any desktop environment.

KWin moved to an own repository

As you might have read in Aleix’s blog post the kde-workspace repository got split into several repositories. KWin was also affected by this change. As the largest module in the old kde-workspace repository and given the fact that it has always been a rather stand alone part in kde-workspace it got moved into an own repository. If you want to clone it just run:

git clone kde:kwin

This change will hopefully make development easier, especially following all commits should be easier. A nice change is that KWin now does the dependency resolving itself which removes quite some quirks we had in the old setup. All of kde-workspace had X11 and a few other dependencies optional, but for KWin they were mandatory. Now all mandatory dependencies can clearly be stated.

The new KWin repository does not contain all source code as it used to. The Oxygen window decoration got moved together with other parts of Oxygen. But this doesn’t change anything for KWin: Oxygen is still the default window decoration, just the dependency is now at runtime. If Oxygen is not around KWin can fallback to the Plastik window decoration just as it used to be.

Furthermore the documentation for the configuration modules got moved into the new repository, so all the documentation is now also directly in KWin. And also the new kwin-compositing-kcm got imported into the new repository. This got initially developed in an own repository to ease the initial development (which started on Qt 5 when KWin was still on Qt 4), but we had the plan to merge it back into KWin once the repositories are split. Note for distributions: you can drop the package in case you packaged it already. Sorry if that created some extra work for you.

Bug fixes for the 4.11 release still need to happen from the old kde-workspace repository as that’s the one used to make the releases. Commits to this branch will get cherry-picked by me to the new repository.

Why the Display Server DOES matter

This weekend I read a blog post by Robert Ancell from Canonical claiming that the display server doesn’t matter . To quote the direct message:

The result of this is the display server doesn’t matter much to applications because we have pretty good toolkits that already hide all this information from us.

Now I don’t know how to put it, the best description is that I’m shocked that Canonical is still not seeing the problems they created by having multiple display servers. I do not know how much experience Robert has with making applications work with multiple display servers, but I at least have this experience as shown in my blog post on making KF5 not crash on Wayland. Granted in this blog post I write that “basically if your application compiles on frameworks it will run on Wayland out of the box”. But that is a strong simplification of the issues which can be present.

With this blog post I will prove Robert’s claim that the display server doesn’t matter due to the toolkit wrong by contradiction. I could just stop here, because I already wrote that KF5 applications were crashing on Wayland prior to me starting to fix these issues. If the toolkit would just abstract away all the display server differences our applications libraries would not have crashed.

Also the assumption that the toolkit behaves the same is just wrong. One of the issues I fixed was Qt returning a nullptr from QClipboard::mimeData on platform Wayland while it returned a valid pointer on all other platforms. It’s obviously an application bug but the documentation doesn’t say that there could be nullptr returned or not. There can be hundreds or thousands of such small behavior differences. An application developer is not able to ensure that the application is working correctly on a distro-specific display server. If the application developer recieves a crash report for such an issue, the developer cannot reproduce the issue – not even on running the same distro with another DE – cannot write a failing unit test, cannot integrate it into the CI system. The most sane thing he could do is declaring that proprietary display server as unsupported. And this should show the problem: each developer will see issues caused by Mir – it doesn’t matter whether it’s in the toolkit, application libraries or in the application itself. Thus an application developer will have to care about the display server. The applications will have to decide whether they want to support Ubuntu.

Another example is different behavior. Look at this screenshot:

Aus Weston

This is the KColorDialog running on Wayland and when I click the pick color button nothing happens and the debug output just says: “This plugin does not support grabbing the keyboard”. It uses QWidget::grabKeyboard – functionality provided by the toolkit. Again the documentation does not tell that it’s not supported on all platforms, it also doesn’t offer API hooks to figure out whether grab is supported. What will be a possible fix for this?

#if Q_OS_LINUX
if (!QX11Info::isPlatformX11()) {
    colorPickButton->hide();
}
#endif

We just hide the button if we are building for Linux but are not on X11. Why is that wrong? Well what if other platforms still support it. So a better way?

#if Q_OS_LINUX
if (QGuiApplication::platformName().toLower().contains(QStringLiteral("wayland"))) {
    colorPickButton->hide();
}
#endif

It’s better, it only hides it for Wayland. But what if the same feature is also not supported on Mir? How should a developer find out to fix that problem properly? How does a developer figure out what the platformName for Mir is? The documentation doesn’t know anything about Mir, the Qt sources (yes I have them on my system) don’t know anything about it. How long will it take till a user reports that the button is broken? Will the user tell that it’s Mir and not a normal system? After all our bug reporting tool reports “Ubuntu” for both Ubuntu and Kubuntu. And on Kubuntu, which the dev might be running, it’s working just fine.

Another example from a patch I prepared to fix an issue:

 #if HAVE_X11
     d->display = qgetenv("DISPLAY");
+    if (d->display.isEmpty()) {
+        // maybe we are on Wayland?
+        d->display = qgetenv("WAYLAND_DISPLAY");
+        if (!d->display.isEmpty()) {
+            // don't go into the xauth code path
+            return;
+        }
+    }
 #else

Now will that code work with Mir given the way it is written? Obviously not. Could I have fixed it? Obviously not, because I have no idea whether Mir has a system like these env variables. What will happen if someone tries to fix it for Mir? I expect the maintainers to tell that this doesn’t scale and needs to be reworked. For two it’s a solution to just test one after the other, but with three systems it doesn’t scale any more. It becomes too complex. So yes the maintainer of this application library has to care about the fact that there are multiple Display Servers.

In summary: Canonical created a huge problem by introducing another Display Server and it’s affecting all of us and they are still in denial state. It’s not a simple the toolkit will solve it. It can cause issues everywhere and that affects the development and maintenance costs of all applications. My recommendation to application developers is to never accept patches for this mess Canonical created. If they want that fixed, they should do it in their downstream patches. Distro specific problems need to be fixed in the distros. I certainly will not accept patches for the frameworks and applications I maintain. This is not for political reasons as it’s so often claimed, but for technical, because I cannot test the patches (Mir not available on Debian) and our CI system cannot build it.

Desktop Effects Control Module in KWin5

One of the new features in KWin 5 is a completely rewritten configuration module for our Desktop Effects. In KWin 4 our module was based on KPluginSelector, which is a great widget for a small list of plugins, but it was never a really good solution for the needs of KWin.

Also we noticed that a QWidget based user interface is not flexible enough for what we would like to provide (e.g. preview videos). So when QtQuick came around we had the first experiments with reimplementing the selector with QtQuick, but with the lack of what today is QtQuick Controls it never left the prototype state. But it encouraged us to use one GSoC project on redesigning the control module from scratch and Antonis did a great job there to lay the foundation for what we have now in the upcoming alpha release.

The most noticeable change is that the new control module just focuses on the Desktop Effects. What we learned from our users is that they are only interested in configuring the effects and that the other options exposed in that control module bare the risk of users changing and breaking their system. Thus we decided to give the users what they need and move all other options into another control module.

In order to give the users the possibility to focus on the effects we also did some cleanup in the list and all effects which are not supported by the currently used compositing backend are hidden by default (e.g. OpenGL effects when using XRender). Also all internal or helper effects are hidden by default. These are effects which replace functionality from KWin Core or provide interaction with other elements of the desktop shell. Normally there is no reason for users to change that except if they want to break their system. That’s of course a valid use case and so there is a configuration button to modify the filtering of the list to show also those effects.

Last but not least our effects got extended by information on whether they are mutual exclusive to other effects. For example one would only want to activate the minimize or the magic lamp effect. Both at the same time result in broken animations. For effects in a mutual exclusive group the UI uses radio buttons and manages that only one of the effects can be activated. That’s the change I’m most happy about.

Check out the video to see the new configuration module in action and also see some of the new features I haven’t talked about. Please don’t tell me in the comments about padding issues and rendering problems. We can see those, too, and are quite aware of them. If you want to help iron out issues with Oxygen and QtQuick Controls check have a look to our wiki page.

House Cleaning in KWin 5

We are currently approaching the release of the first alpha version of KWin 5. This is of course a significant milestone and we have put lots of work into the transition to ensure that it’s already working quite fine. With such a big migration it is also important to not only work on new cool stuff, but also to do lots of house cleaning.

For example last week the build option for disabling scripting support got removed as we consider scripting as an important and integrated part of KWin. Thus during the house cleaning the build option got removed.

And of course there are areas where we wanted to remove some legacy code for quite some time but never really dared to do. Two years ago I already discussed the costs of supporting the legacy OpenGL 1 compositing backend. Now it was time to re-evaluate the situation.

KWin 5 is a strong user of QtQuick 2. In fact almost all user interface code is written with this new framework – be it the close button in Present Windows, the window switcher or (since today) the outline shown when using quick tiling/maximization. QtQuick 2 uses an OpenGL (ES) 2 powered scene graph thus KWin already has a runtime dependency on OpenGL 2. And in opposite to our Compositor this is a required dependency. While it has always been possible to disable the Compositor (and that won’t change for X11), it is not (yet) possible to disable the OpenGL usage of QtQuick.

Thus we have to ask whether it’s still worth keeping a code path for legacy hardware, if we require newer hardware. Combined with all the problems mentioned in the above linked blog post from two years ago it becomes really questionable to keep the code.

After some preparation to ensure that we have a clean cut I pushed today the changes to remove the legacy OpenGL 1 compositor in order to have this change in Alpha 1. We encourage all users who used to run the OpenGL 1 compositor to try with the OpenGL 2 compositor and also with the still supported XRender based compositor. If you run into any severe issues please report a bug (or check whether one has already been reported) and provide the support information. This will help us to iron out any issues, like ensuring that no effects get loaded which are not suited for your hardware. After all the base OpenGL 2 compositor should not be an issue for most hardware. But some effects are more demanding than the compositor itself and those can be disabled automatically. Also we try to keep the impact low. If our logic recommended OpenGL 1 compositing for a specific set of hardware, it doesn’t enforce OpenGL 2 now, but uses the better suited XRender compositor.

“KDE5″ and Wayland

Recently I have seen many comments by users in the style of “I’m looking forward to the first release of KDE5 because of Wayland”. With every time there is such a comment the chances are that it spreads that the first release of “KDE5″ will support Wayland and will result in disappointment when the first release of something ends up on the users’ systems. Thus I decided to write a blog post with clarifications.

As my readers probably know there won’t be a combined release as the software compilation used to be. There are independent ongoing projects around the libraries (frameworks or KF5) the workspaces (Plasma Next) and the applications. These projects have independent release cycles and are not one product. I know, I know, many people will disagree and say that it’s still one. But if we go for this strong simplification both “will support Wayland” and “will not support Wayland” are true.

And thus we enter the area where it is important to make the distinction between the various products and use the correct name. Otherwise people don’t know what you are talking about and it results in confusion.

So let’s look into the different areas. As I have already explained our libraries are getting prepared for Wayland and the first release of KF5 will have Wayland support not on par with X11 support but certainly on par with Microsoft Windows or OS X support.

This means for applications using our frameworks that they will support Wayland as long as they don’t speak X11 directly.

For the workspaces it’s more complex. Our aim for the first release of Plasma Next has never been to fully support Wayland or do the migration to Wayland. We obviously don’t want to create too many construction sides and decided to concentrate on getting everything ported to Qt 5 first before going to Wayland. As we are entering the alpha release state shortly we can be quite certain that the Plasma desktop shell will not support Wayland. Other parts of Plasma Next have a little bit more integration, some systemsettings modules get hidden when running on Wayland, some modules got fixed to not crash, KInfoCenter got some improvements to support the OpenGL module on Wayland and got a new Wayland module. KWin is still in the experimental support stage not yet being a Wayland compositor. Here we might still have some improvements till the final release as Wayland specific code is excluded from the feature freeze. But overall we can quite certainly say that the first release of Plasma Next will not support Wayland.

System Tray in Plasma Next

In the past the system tray was implemented using the xembed specification. An application which wants to use the system tray creates a small window which gets embedded into the system tray. This means that the control over this area belongs to the application and not to the desktop shell hosting the system tray.

The result is that each item in the system tray may behave differently. Some set a different cursor, thus the cursor is flickering if you move from one icon to another. Some open/close the application when clicking the icon, some might provide a context menu on right mouse click or interact with further input events. But what is present in all cases is that there is no consistent behavior. From a user experience point of view this is very bad as the users learn that the system is inconsistent and works in an unexpected way.

Some years ago the Plasma hackers started to address these issues by implementing a new specification called Status Notifier. This specification got also adopted in Unity/Ubuntu as the Application Indicator. The new specification addresses the issues outlined above as the control is moved to the hosting desktop shell. This allowed us in Plasma to provide a consistent look and feel by using the monochrome icons and controlling which items to show when.

But still we supported the xembed system tray specification for legacy applications which were not adopted to the new specification. This means that all the issues are still present. It’s still possible that an item behaves completely different because it’s using the legacy protocol.

When we drafted the plans for the new implementation of the system tray in Plasma Next we of course also discussed the future of the xembed based implementation. It was a challenging topic as we want to go to Wayland and obviously an xembed based system tray icon won’t work on a Wayland powered system tray (yes in theory it could work through XWayland). Also getting the xembeded window integrated into our QtQuick based system tray is not the most trivial task.

Also some of the design aspects just don’t work with the legacy system tray. We want to support reasonable dpi and xembed items are hard coded to 22×22 pixels, that’s probably a lot of fun on a high dpi screen. We also want to categorie the system tray items, so that they are logically grouped. For that the status notifiers allow to tell us that it’s an application item and whether it’s currently passive, active or demands attention. This gives the host the required power to properly place the item. But with the legacy system tray we are just lacking this information and don’t really know what to do with an item.

QSystemTrayIcon as xembed in Plasma Current and status notifier in Plasma Next
QSystemTrayIcon as xembed in Plasma Current and status notifier in Plasma Next

When we discussed all these issues it became apparent that we do not want to invest the time in implementing the legacy system for Plasma Next. Nevertheless we do not want to break the functionality of existing applications. So we investigated ways of how we can ease the transition. KDE applications use the status notifier already and most GTK+ applications also use the appindicator library for unity integration, so they just work the way we want it. But for example the QSystemTrayIcon still uses the legacy system on X11. As it’s Qt there is also the QPA-API which allows us to provide Plasma-specific implementations through our platform theme. That’s the approach we decided to go: force any QSystemTrayIcon to use the status notifier API through our platform theme. Unfortunately the QPA-API was not sufficient for our needs and thus we had to extend it, which will be available in Qt 5.3. If Qt base is compiled with X11 support the QPA system is not used at all and the change to fix this slightly missed the 5.3 merge window. The last missing bit to get this work is in our frameworkintegration repository to implement the required API. This is currently under review which means that it will be available once we release our first release of Plasma Next. Though it will take until Qt 5.4 till the feature will be working properly. As a nice side-effect this also adds an implementation for QSystemTrayIcon on Wayland/Plasma.

Although we invested lots of time into making it work as smooth as possible there will be applications for which the system tray icon will not be working. Nevertheless, we decided to not implement support for it as we want to focus on the core and it was not justified to invest lots of time on an implementation only needed for a short period of time. Applications still using Qt 4 will hopefully soon get ported to Qt 5 and then the issue fixes itself. Overall from an end-user perspective this means that nothing really changes. The system tray is still going to work, in fact it will be better as all items can be scaled, themed, behavior adapted to input methods, logically grouped and much more. Nevertheless it’s possible that there are applications which still use the legacy protocol and that will break. In case it’s an open source application it will be easy to fix and we as the Plasma team are happy to help as much as we can. And in any case Plasma is a very flexible framework allowing you to implement an alternative system tray which supports the xembed system tray. It doesn’t have to be the core team which keeps the compatibility with the legacy system.

Running frameworks powered applications on Wayland

After I got KWindowSystem to no longer require X11 on Linux I dared to start some of our applications which got ported to frameworks 5 with the magic “-platform wayland” command line switch. And look there: they started and were useable. But there were some obvious problems: e.g. our platform integration plugin was not loaded. But with a small change to Qt 5.3 this problem is solved. Now if you run a Wayland compositor in a KDE session you will get the KDE integration as one would expect. But this just openend a new set of problems: our default QStyle (Oxygen) was crashing any application on startup as it was still assuming that it’s on X11 if compiled with X11 support. Easy enough to fix and now Oxygen works as one would expect.

This experience highlighted an obvious problem: our applications will crash if they are compiled with X11 support and do not perform a runtime check. So I started to hunt down possible crashers in our libraries. In the perfect world there should not be any X11 specific code in the libraries (except KWindowSystems). And luckily our libraries supported non-X11 platforms for quite some time, so all the X specific code should be in HAVE_X11 blocks. So a small reminder for everybody who thinks that we should never have supported Windows in the first place: thanks to Windows support most of our applications just work on Wayland. Have a look at this nice collection of applications which are running just fine on Wayland:

Aus Weston

Right now we have reached a state where I am no longer able to crash applications at random and most applications which I give a try just work. We had a few problems in kde4support which prevented any applications which still used K(Unique)Application to start at all on Wayland and that framework had stronger usage of HAVE_X11 than I expected. Although the framework is deprecated I fixed all the issues I could find in it, to get applications to support Wayland faster. Basically if your application compiles on frameworks it will run on Wayland out of the box. Also thanks to that work our applications will just work on any proprietary windowing system (so no need to be upset that we put more work on e.g. Windows support than on your small pet project). My personal aim is to have Wayland support at least on par with Windows support in our first release of frameworks. Later on we will improve it to get it on the same level as X11 support.

Of course it’s possible that I haven’t spotten all crashes in the libraries yet. And I encourage our application developers to test their applications on Wayland. That’s quite simple in fact: just start Weston (can be nested in the X session) and prepare the setup:

source kf5_env.sh # your kf5 environment variables setup script
unset DISPLAY # to make sure that any XOpenDisplay call will fail
export WAYLAND_DISPLAY=wayland-0 # adjust to whatever you used in Weston

Now all you need is to pass “-platform wayland” to the command line args to start your application on Weston. In case you are using a KApplication and KCmdLineArgs you need to use “--platform wayland” instead. Update: as an alternative one can also export the environment variable “QT_QPA_PLATFORM” and set it to “wayland”. If you run into any problems with it, feel free to ping me on IRC. In case you get your application to crash in one of the frameworks and it’s a crash due to using X11, please report a bug and set me on CC. In case you hit a crash in your application there is a very easy pattern to solve the problem:

#if HAVE_X11
if (QX11Info::isPlatformX11()) {
    // do your X specific calls here
}
#endif

If you are not using QX11Info you can also do:

#if HAVE_X11
if (QGuiApplication::platformName() == QStringLiteral("xcb")) {
    // do your X specific calls here
}
#endif

As you can see it’s performing a string comparison so you don’t want to have that in a code path which gets called often. Recommendation: move it into a member variable which gets initialized only once in app life cycle and also ifdef the variable – no need to do these checks on e.g. Windows. If you have any questions with it, feel free to ask me.

In the workspace module I hit a few crashers in modules which make absolutely no sense on non-X11. The code is too X specific and most likely needs a complete rewrite if we want to have it on non-X11. Of course we don’t want to have modules which just crash in systemsettings. So I introduced a new method to KService to check whether the plugin makes sense on the current Qt platform. This is honored by ::noDisplay() so systemsettings (and also kcmshell5) won’t pick them. To specify one can use e.g.

X-KDE-OnlyShowOnQtPlatforms=xcb

in the plugin’s desktop file. There’s also a “X-KDE-NotShowOnQtPlatforms”.

KWindowSystem in Frameworks 5

KWindowSystem is a tier 1 framework which allows to interact with the windowing system. Historically it provided an implementation of NETWM on X11. It provides a NETRootInfo for accessing the global state (all that’s set on the root window) and NETWinInfo for all information about a specific window. The classes have a window manager and client perspective. This is the foundation which powers our window manager and various parts of the desktop shell such as the taskmanager.

On top of those X11-specific classes we have a convenient API KWindowInfo and KWindowSystem which provides a windowing system independent API for our applications. Thus we have different implementations depending of the platform it’s compiled on. On X11 the implementation depends on named NET* classes, on Windows and Mac what makes sense is implemented using the platform specific API.

In the good old days of Qt 4 this was a sufficient solution. If it’s build on unix-like systems we have X11 and we know it’s X11, on Windows it’s Windows and so on. With Qt 5 this no longer works. Just because we built with X11 support doesn’t mean the software will run on X11. Due to the introduction of the QPA it’s possible that another platform is used – most obvious Wayland. But there are more platforms for Linux like Android. With the solution from Qt 4 our applications would just crash as soon as they access KWindowSystem as that tries to interact with XLib/xcb unconditionally.

Over the last weeks I spent quite some time on making sure that KWindowSystem works as expected (that is doing nothing at the moment) when run on Wayland. Just adding a new implementation as in the Qt 4 days is no solution as we want our framework to support both X11 and Wayland at the same time. Otherwise our distributions would have a hard time packaging our software. The approach was to introduce an internal abstraction in KWindowInfo and KWindowSystem and have a platform implementation. This is now done for X11 together with a dummy implementation which is used as a fallback if we do not have an implementation for the currently used windowing system (e.g. Wayland). Unfortunately this has a side-effect: it broke the backend for Windows and MacOS. I don’t feel very happy about it as I don’t like to break the work of others, but I cannot fix it. Windows and MacOS are proprietary systems for which either a license or even specific hardware is required. I do hope that the specific teams will re-add the support till the release of frameworks 5. Please note: at the time of writing this blog post not all patches are merged yet.

A nice side-effect for this work was that I started to write unit tests for KWindowInfo on X11. This is far from trivial as it interacts with X11 and the running window manager. And the test kind of depends on the used window manager. Obviously given that it’s KDE it would make sense to write the test against KWin, but that’s not sufficient for our CI system as kwindowsystem is a dependency of KWin and thus kwindowsystem cannot depend on KWin (not even on runtime). Thus the tests are now performed against openbox on the CI system, but also succeed when running against KWin. They are quite a stress test for a window manager and found one very unlikely crash condition in KWin (of course already fixed).

The framework provides more functionality which is kind of X11 specific. For example there is the KSelectionOwner and KSelectionWatcher which implements a manager selection as described in ICCCM, section 2.8. Again a very important building block for our window manager. While it’s clearly X11 specific code which only gets built if X11 is available, there is no reason to crash if it’s not run on X11. So I went through all of our sources and tried to make sure that it correctly checks whether the runtime platform is xcb. Thus we don’t have to change all applications using it, but can rely on the library not to crash. Still if your application is using these X11 specific functionality I highly recommend to check for the platform as you might run into runtime errors. E.g. claiming a manager selection will fail, don’t rely on it.

As all of this is kind of a requirement to running frameworks based applications on Wayland, I have to do the obligatory screenshot of Kate on Weston:

Aus Weston

Plasma sprint in Barcelona

The last week I spent in the BlueSystems office in Barcelona for this years Plasma sprint. It was a wonderful timeing given that we are just approaching the last stages of preparing our first release based on Qt 5 and KDE Frameworks 5. We had some very good discussions and summaries of those can be read in sebas’s blog as well as on the Plasma mailing list.

My main focus for the sprint was obviously KWin and the Wayland port of the workspace. In that area I mostly worked together with Alex. For example we looked at all of the kde-workspace module to figure out what currently expects X11 in an unconditional way. Such code needs either to be ported or at least to be made runtime platform detectable.

Overall I tried to update the team on the current state of KWin/5 and KWin/Wayland and to highlight the next steps. I have some ideas on how to further change KWin/5 and the sprint was obviously a good opportunity to discuss the ideas in person and to get feedback. Of course I will also announce the changes on my bloge once they are implemented.

Some of the overall changes we discussed will also affect KWin. We are considering to split our monolithic kde-workspace module and that would most likely result in an own repository for KWin. This could allow us in future to experiment with more things. One of the ideas I got during the sprint was to do rapid release cycles for KWin once we did the first release on Qt 5 in order to bring the new Wayland code faster to the users.

Our most important discussions in the Plasma teams might have been a look at our tooling and processes. We identified quite some shortcomings and have good ideas on how to address those. And we did not even keep it by just talking we started to implement the changes right at the sprint. An outcome is that we sent summary mails about the discussions to the mailing list. These summaries are intended as blue prints and not as decisons. So anybody can provide feedback and it’s not required to have been at the sprint. We hope that this makes our community way more inclusive.

From the tooling perspective we also had a look at a FLOSS replacement for Trello boards and are quite interested in one of them. If we implement it, this could become a wonderful tool to get the work better distributed and more inviting for the community. It should make it much easier for developers to just go to the board and pick a task. Personally I’m quite satisfied with the experience I made with the Trello board for KWin so far and am glad that KWin could act as an experimental area for this workflow change. I use this opportunity to point out that the Trello board still has a large number of easy tasks and I’m still adding new tasks whenever I find a new one.

Creative Commons Attribution-ShareAlike 3.0 Deutschland
This work by Martin Gräßlin is licensed under a Creative Commons Attribution-ShareAlike 3.0 Deutschland.