Fallback mode in KDE Plasma Workspaces

Recently there has been a lot of buzz about non-composited fallback modes in various Desktop Shells and of course I have been asked several times about the fallback modes in KDE Plasma workspaces and whether they would be removed, too. Now instead of answering the same question again and again I decided to write a blog post to discuss the situation in more detail.

The first thing to notice is that KDE Plasma workspaces do not have a non-composited fallback mode in the way GNOME Shell or Unity used to have. The main difference is that our window manager (KWin) is able to act as a non-composited, XRender based compositor and OpenGL (ES) based compositor. This means that we do not have to maintain two window managers in order to provide non-composited setups.

The second major difference is that the Desktop Shell (either KDE Plasma Desktop, KDE Plasma Netbook or KDE Plasma Active) is not a plugin to the compositor but a separate application running in an own process. This allows to use a completely different window manager together with the Desktop Shell. Some years ago it was not that uncommon to use Compiz together with Plasma, though we see less and less such usage patterns (mostly caused by Compiz no longer being available in most major distributions except Ubuntu). This is a design decision which served us well and we do not plan to change it. Some time ago I brought up the topic, but more experienced developers (mainly Aaron) illustrated nicely the advantages of our design choices.

Of course we need some code to be able to adapt to non-composited mode inside the Plasma workspaces. But this code would be needed anyway. Why? To answer this question we have to go back in time to when the development of Plasma had started – that is around 2006/2007. Back then OpenGL based compositing had been a rather new topic (I think I first heard about Compiz in 2004 or 2005) and it had only been possible with the binary blobs and hacks such as Xgl. The Intel hardware back then was not powerful enough and drivers were lacking, too. With other words: going an OpenGL-based only path seemed not feasible at that time and consider that the fallback modes in Unity and GNOME Shell got only removed in late 2012/early 2013. This is more than half a decade later – an eternity in IT. Also KWin did not enable compositing support by default till 4.2, so the first releases of KDE Plasma were non-composited by default.

The solution inside Plasma was to make our themes aware of compositing. That is each theme contains an opaque element set which will be used when in non-composited mode. The fact whether compositing is used, is globally available through a standardized X11 manager selection. So whenever the compositing state is changed Plasma is notified and switches the used elements. Simple and elegant. This functionality served us quite well when we introduced the blur effect. Translucency is actually a very difficult topic. If you choose a too strong translucency level the text is no longer readable, if you choose a translucency fitted for text readability the translucency is hardly visible. The solution to this problem is the blur effect. It provides easily readable text even with strong translucency levels. But even today we do not enable the blur effect by default on all hardware as it is an expensive effect and we would not dare to enable it on embedded devices (personally I doubt that Windows 8 removed the blur because the designers disliked it). So we see we need themes with different levels of translucency depending on whether blur is available or not. The design decisions for the Plasma themes provided us the solution directly. As well it means that even if we would drop the non-composited mode we would have to keep our design to support the blur selection.

For most of the applications it hardly matters whether the desktop is composited or not. Only very few applications use the alpha channel in the first place and if they want to use it, everything’s nicely abstracted inside Qt.

Inside the window manager it also doesn’t really matter. Of course our window decorations are aware of whether compositing is used or not and especially Oxygen makes use of it by providing an adjusted look for the non-composited case, so there we have some overhead, but except that there are hardly any adjustments.

This also means that we would not gain anything from requiring compositing. The compositor is a separate module inside the window manager which just gets started by the window manager on start-up. It lives more or less for itself and is just notified when a new window is added to the window manager and so on. Nothing inside the window manager really depends on the compositor. That means it would be more work to get KWin requiring compositing than to keep supporting the non-composited mode. And having the non-composited mode around allows us to do things like turning compositing off when running games or heavy OpenGL based applications such as Blender. So if you want to get some of the now finally available games for Linux, KDE Plasma should be your primary choice to enjoy the game. I have also heard of users switching to KDE Plasma because we still provide non OpenGL based setups.

What remains is the question of what will change with Qt 5? Obviously not much. Plasma will continue to provide a non-composited and a composited theme, but Plasma itself will require OpenGL due to being based on QtQuick 2. I do hope that llvmpipe will be sufficient for Plasma in case of non available drivers. The same is true for KWin: our QtQuick based elements will require OpenGL 2, but that does not mean that we will require OpenGL based compositing. We will still provide non-composited mode and if the XRender based compositor get’s ported to XCB (we have lots of work there to get involved ;-) will continue to provide XRender based compositing as well as OpenGL 1 and OpenGL 2 based. Since the refactoring of the OpenGL based compositor I do not see much difficulties with keeping the OpenGL 1 based compositor around, though if it turns out to not be used anymore, it might be removed.

The last remaining question is what will change with Wayland? Obviously Wayland requires to have a compositor, but it does not require us to stop supporting X11. KWin will continue to be an X11 based window manager allowing you to not use Wayland at all. And even if you choose to use a Wayland based KWin nothing says that it needs to be a compositor on top of OpenGL. Whether we will provide non-OpenGL based compositors for Wayland is a question for the future, though.

A final remark: this blog post describes the situation inside the KDE Plasma workspaces and the design decisions we have done. This is not a critic at the design decisions other projects have done and I am not able to judge whether their decision is right or wrong and it is completely irrelevant what my opinion is on their decisions.

What is a Desktop?

A few days ago I started to work on a part of KWin which made me wonder what do we mean with the word “desktop” in the context of a window manager such as KWin. Of course in the sense of a window manager one means “Virtual Desktops” when speaking of “desktop”. Wikipedia says about virtual desktops:

In computing, a virtual desktop is a term used with respect to user interfaces, usually within the WIMP paradigm, to describe ways in which the virtual space of a computer’s desktop environment is expanded beyond the physical limits of the screen’s real estate through the use of software.

Inside KWin we identify the virtual desktop through mostly two properties in our Workspace class: currentDesktop and numberOfDesktops. In the X11 world the usage of virtual desktops is furthermore specified through the Extended Window Manager Hints (EWMH) which defines the root window property _NET_NUMBER_OF_DESKTOPS as:

This property SHOULD be set and updated by the Window Manager to indicate the number of virtual desktops.

And the root window property _NET_CURRENT_DESKTOP as:

The index of the current desktop. This is always an integer between 0 and _NET_NUMBER_OF_DESKTOPS – 1. This MUST be set and updated by the Window Manager.

As we can see the naming inside KWin is influenced by the specification which is implemented.

Normally an X11 window manager implements the “virtual space” by putting windows on a virtual desktop. This is controlled in KWin inside the Toplevel class by having a property called desktop which directly reflects to the EWMH specification’s property _NET_WM_DESKTOP:

Cardinal to determine the desktop the window is in (or wants to be) starting with 0 for the first desktop. A Client MAY choose not to set this property, in which case the Window Manager SHOULD place it as it wishes. 0xFFFFFFFF indicates that the window SHOULD appear on all desktops.

The last aspect of the specification tells us that the desktop number “-1″ is used to say that a window is on all desktops. Inside KWin we map that to a boolean property onAllDesktops.

When looking at the source code of Toplevel related to desktops it is very easy to get confused due to the two following methods:

bool isDesktop() const;
int desktop() const;

So there is both a boolean and an integer property called “desktop”. That does not make any sense. How can a desktop be a boolean value? Looking at the Q_PROPERTY value helps us to resolve the confusion: the boolean property is there called “desktopWindow” which refers to a window type as provided by the EWMH specification:

_NET_WM_WINDOW_TYPE_DESKTOP indicates a desktop feature. This can include a single window containing desktop icons with the same dimensions as the screen, allowing the desktop environment to have full control of the desktop, without the need for proxying root window clicks.

In the KDE world that is our plasma-desktop application. A more modern name would be “shell” as we nowadays speak of Desktop Shells. Funnily enough a desktop window is normally not on any desktop.

In order to get access to the desktop shell there should not be any windows in front of the desktop. To provide easy access there is the concept of “showing the desktop”. All windows are temporarily removed when entering that mode and restored afterward. Inside KWin this is controlled by the boolean property showingDesktop of the Workspace class which is again influenced by the EWMH property _NET_SHOWING_DESKTOP:

Some Window Managers have a “showing the desktop” mode in which windows are hidden, and the desktop background is displayed and focused. If a Window Manager supports the _NET_SHOWING_DESKTOP hint, it MUST set it to a value of 1 when the Window Manager is in “showing the desktop” mode, and a value of zero if the Window Manager is not in this mode.

Overall we see that inside KWin we have three completely different concepts denoted by the word “desktop”:

  1. Virtual Desktops
  2. A window which is the Desktop Shell
  3. Showing Desktop Shell Mode

I can imagine that for developers having a look at the code for the first time this can be quite confusing. We see here a general problem in programming when one does not clearly define the concept in the naming. In this case the naming is fuzzy and can only be understood by someone with domain knowledge.

Now how come I wrote this blog post? I started to further refactor Workspace and split out the handling of virtual desktops into a VirtualDesktopManager. This manager is supposed to take care of all aspects of virtual desktops like telling us how many there are and which is the current. While looking through the code I noticed how many methods there are with “desktop” in it which have nothing to do with virtual desktops. That made me wonder what else a desktop can be except a virtual desktop.

It’s still quite some work till that code will be ready especially as I want to add unit tests to the new Manager but the improvements to the overall code base are already visible. The name makes clear that it is about Virtual Desktops and not about the Desktop Shell or the Showing Desktop mode and due to the class being just about Virtual Desktops the smurf-naming of all methods and properties could be removed. Much cleaner and easier to read. And of course the Workspace class is again losing a few hundred lines of code which is always a positive thing.

This week in KWin (2012 week 44, 45)

The last two weeks have been very important in the KWin development area. First there was the release of 4.9.3 which includes a very important performance bug fix for Mesa 9.0 Intel users. If you had problems please consider an upgrade.

On Thursday we had the hard feature freeze and many features got merged in during that period. Bellegarde Cédric merged in the appmenu support, allowing to have the window’s menu inside the window decoration. I love it as it’s very clean and I hardly use the menu in any application.

Fredrik merged in the initial port from XLib to XCB. This is an important step on the road towards Qt 5 support inside KWin and will probably require still quite some work during the 4.11 cycle.

Casian Andrei’s Google Summer of Code project on color correction got merged in as well. Unfortunately the merge did not go well, so there is still some work to do before the beta release. I hope that I can point to some documentation how to setup a color corrected system very soon.

We have received a nice performance improvement for moving windows when using compositing. This should help alleviating some choppiness when using vsync.

I merged in an improvement to window decorations, so that they can inform the compositor when they are not translucent. This improves the situation for rendering e.g. a maximized window with Oxygen but is most important for the new Plastik QML decoration which is not using translucency at all.

Due to so much going on during these two weeks I’m sure that I have forgotten to mention something important. This could be summarized as “I don’t like feature freezes” – it’s so un-git.

Summary

Bug Fixes

  • 308633: Window tab group separated in shaded windows
    Git Commit
  • 308759: Forgotten “${…}” witihin CMakeLists.txt
    This change will be available in version 4.10
    Git Commit

New Features

  • 102607: Display application menu and title bar side by side for maximized windows
    This change will be available in version 4.10
    Git Commit
  • 296773: GHNS support for Scripted Effects
    This change will be available in version 4.10
    Git Commit
  • 308995: Support shortened titles like in bespin in all decorations
    This change will be available in version 4.10
    Git Commit
  • 308990: Animate Window Maximize/Restore
    This change will be available in version 4.10
    Git Commit
  • 266596: Add support for appmenu-qt
    This change will be available in version 4.10
    Git Commit

Notice for users of KWin master

With KWin master as of today the configuration of the Translucency Effect changed. It used to have translucency values in the area [0.0, 1.0] which got changed to [0, 100]. If you rebuild and just restart KWin it might be that you do not see any windows at all, because the windows are completely translucent.

To circumvent this problem run the KConfig Update application in $KDEDIR/lib/kconf_update_bin/kwin_update_settings_410 or just log out and log in again.

Users not running master are of course not affected by the change, the KConfig Update handles it correctly on first login after update.