Posted on

Introducing KWayland::Server

A few weeks ago I blogged about the new KWayland module in our workspace modules. Back then I also mentioned the server component of KWayland and that it’s not part of the 5.1 release. Yesterday I finally committed a change to install the library and the header so that starting with Plasma 5.2 the server component is also available. This is a good point in time to explain what the server library is and what can be done with it.

Like the client library the server library is a very low-level Qt wrapper for the Wayland server library. So the main task is to be a Facade to wrap the C library in a for us easier to use Qt style API. E.g. it’s emitting signals when the C callbacks are invoked and hides all the required C casts of void pointers. Nevertheless we still have access to all the wraped Wayland members, so it allows to easily combine KWayland::Server with wayland server code.

KWayland::Server is not a wayland compositor. It is deliberately designed to be head-less, which makes it a wonderful solution for using as a backend for automated tests. E.g. for kscreen it is used to simulate changes in the screen setup which is a huge improvement over the state we have on X11 where there is basically no chance at all to test screen changes.

Although the library is head-less the repository contains also some test applications including a wayland compositor which can render:

Aus KWayland

The actual compositor is a good old QWidget connecting to the X-Server. It starts a Wayland server and can render the buffers provided by connected clients, in this case KInfoCenter showing the Wayland module (which uses KWayland::Client). KInfoCenter is run using the Wayland QPA, so it’s a native application and doesn’t use X11 at all.

Overall this test compositor is just about 200 lines of code and supports not only rendering, but also input as can be seen in this screenshot of kate:

Aus KWayland

Unfortunately the KWayland::Server module doesn’t support the test applications provided by Weston yet. The reason for this is that those applications expect the xdg-shell protocol to be present. But this protocol is not yet supported by KWayland::Server and won’t be supported any time soon, due to the unstable nature of that protocol. So for the time being one can only test with QtWayland and the small set of test applications provided by the KWayland repository (those can of course be run against Weston).

Of course there is still a lot of work to be done in the server module – the code is full of TODOs. Helping hands are of course welcome and Google Code-In students can expect a few tasks around the KWayland::Server module 😉

Now that the server module gets installed we can start using it in applications. I have a plan where to integrate it for the 5.2 release (teaser: it won’t be KWin) and depending on how much time I find for it, kwin_wayland might also get to the state that it starts a server. But Christmas and feature freeze are approaching, and there is still lots of other things to work on.

If you like the work we are doing, consider donating to KDE:
KDE donation campaign

The donations are used to e.g. sponsor developer sprints where we can discuss the implementation of Wayland in the Plasma workspaces.

Posted on

Window and Desktop Switcher moved to Look’n’Feel Package

Today we did an important change in how KWin will distribute its assets in the upcoming 5.2 release. When we started our thoughts about the Look’n’Feel Package and how we want to have meta themes for the complete Plasma workspace we also wanted to have this for the Window and Desktop switcher provided by KWin. So the structure of the Look’n’Feel Package already has all the pieces for including the Window and Desktop Switcher, but it was not used. Now we finally addressed this for the 5.2 release and moved the default switcher into the Look’n’Feel Package and KWin can locate the switchers from the Look’n’Feel Package.

At the same time we want to follow in a better way the “Simple by default, powerful when needed” approach. Our configuration should be simple and thus not offer an overwhelming amount of switchers. But it also should be powerful and thus one can install additional switchers either through GHNS or through your package manager. The result is that all the additional switchers so far shipped with KWin were moved to kdeplasma-addons repository. So all switchers are still available (powerful when needed), just not shown when opening the configuration menu (simple by default).

This also opens the door for including more switchers in the plasma addons repository. So far we had been very reluctant to add more switchers to the KWin repository. There were already too many switchers installed by default and it gives a feeling of we don’t know what we want. By only installing one switcher by default this improves significantly and allows to add high quality switchers with enough differentiation to other switchers to the plasma addons repository.

The change has also some implications for users of non Plasma desktop environments wanting to use KWin as their window manager. By moving the switchers out, KWin removes some of the Plasma dependencies. All switchers provided by KWin are using Plasma components, the default switcher is part of the design concept for Plasma 5 following the same idea as other similar components. Thus KWin had a direct dependency on Plasma with the window switchers. This is now kind of solved by not offering any switcher at all.

My suggestion for desktop environment projects wanting to use KWin is to provide their own default Look’n’Feel package with a Window and Desktop switcher specific for their environment. On the other hand I don’t see a problem with providing a simple fallback theme in KWin. And of course there are still the Desktop Effects for switching between Windows (CoverSwitch and FlipSwitch) installed by default and just need to be enabled.

Posted on

Window decoration themes in KDecoration2

Most of the window decorations available for KWin are not native decorations but themes for a native theme engine, such as deKorator, Smaragd, QtCurve or my own Aurorae. Themes are much easier to design and to distribute than a native decoration which has to be implemented in C++ and be distributed by the Linux distribution. Thus themes are an important part of the decoration system.

But we did a very bad job of integrating the themes into our configuration system. The configuration system only knows about native decorations and doesn’t know that the native decoration is in fact a theme engine. This makes selecting a theme difficult, because a user has to first select the theme engine and then configure this to select the theme. Downloading new themes through GHNS is also difficult as again it requires to go through the configuration of the theme engine. We can do better.

With Aurorae I tried to address some of the problems by extending the configuration system to know about Aurorae, to be able to find the themes and render previews for it. This only worked because Aurorae and the configuration module are in the same source tree and could share code. Nevertheless it needed to have multiple code paths in the configuration module to load the native themes, Aurorae’s SVG themes, Aurorae’s QML themes and to render the three different kind of themes.

The solution works for one theme engine, but others are still not supported. Which is something I find very sad as it turns the theme engines to second class citizens and also looks bad as my theme engine has full support while others don’t, while doing as a good or even a better job at themeing than Aurorae.

When I started to think about KDecoration2 and started to draft the API design I wanted to make sure that theme engines become a first class citizen in KWin. Last week I started to port the Aurorae theme engine to KDecoration2 and added the missing pieces to make KDecoration2 fully theme aware. The configuration of the selected theme is moved into the framework and the selected theme is passed to the native plugin when a Decoration gets created.

As a result of this work the command line options for kdecoration-viewer changed to:

kdecorationviewer [plugin] [theme]

which allows us to load for example the plugin for Aurorae with one of the SVG based themes:

To announce support that the decoration plugin is a theme engine, the decoration plugin has to put some information into the JSON meta data:

"org.kde.kdecoration2": {
        "themes": true,
        "defaultTheme": "kwin4_decoration_qml_plastik",
        "themeListKeyword": "themes"
    }

If the value for themes is present and true the framework will pass theme information to the Decoration. The framework looks in its configuration for the theme to be used, if there is none it falls back to the defaultTheme from the JSON meta data. The configured theme is passed to the Deocration when being created through KPluginFactory::create which takes a QVariantList as argument. As first element the framework passes in a QVariantMap with a key/value pair of “theme” as key and the configured theme as the value.

The last value of the meta data above is themeListKeyword which is used by the configuration module to locate all themes and provide them. I have not yet finalized the mechanismn so this is still experimental code. The keyword is used to create a different Object through the KPluginFactory. Right now this is a QObject with a QVariantMap property called “themes”. Each key is the user visible name and the value is the internal plugin name. That’s enough information for the configuration module to create a dedicated instance for each of the themes, create a preview for it and properly load/store the information. It allows us to have a configuration module which currently looks like this:

This new configuration module does not have any Aurorae specific code any more. It just knows about plugins and themes and can display them all. As one can see in this screenshot the KCM does not need to know whether it’s a QML based theme (e.g. Plastik) or a SVG based theme (all the others). Which is a nice improvement to the situation before.

The mechanismn for locating the themes will probably change and be moved to KDecoration2 directly. It needs some more tweaks to expose GHNS information and support looking for new themes and deleting existing themes. So there is still a little bit of work to be done. But overall the state is now looking really good and I will soon start the review process for the new API so that KDecoration2 will land in Plasma 5.2. Of course that will be faster if we get more help to finalize the last missing pieces.

Posted on

Libinput integration in KWin/Wayland

Today I pushed my outstanding branch to get libinput support into kwin_wayland. Libinput is a very important part for the work to get a full Wayland session in Plasma which means we reached a very important milestone. As the name suggests it allows us to process input events directly. KWin needs to forward the input events to the currently active application(s) and also interpret them before any other application gets them. E.g. if there is a global shortcut KWin should intercept it and not send it to an application.

Why libinput integration in KWin?

KWin/Wayland already supported input handling by being a Wayland client and connecting to a Seat. But especially for pointer events this was not sufficient at all. We have quite some code where we warp the pointer and Wayland doesn’t support this (and shouldn’t). Warping the pointer is normally considered evil as it can introduce quite some problems if applications are allowed to warp the pointer. E.g. it can create security issues if you start typing your password and a malicious applications warps the pointer to trick you entering your password into a password field of the malicious application. Also from a usabililty perspective it can be problematic as it makes the system behave in an unpredictable way.

On the other hand if the application is a window manager/compositor the need for warping cursors arises. For example the screen edge handling pushes the cursor slightly back which needs cursor warping. Or you can move a window with the cursor keys (hold Control key to have very precise moving) and in these cases we need to warp the pointer. With libinput this is possible again as KWin gets put in control of the input events directly. It completely bypasses the currently used Wayland compositor.

Libinput is also an important piece in the puzzle for a full Wayland session which does not rely on another Wayland compositor. So far KWin/Wayland can only be used in a nested scenario – which is important for development and interesting new possibilities like the idea for a SoK project – but we also want full support without the need for a Wayland session. This means we need to handle input (which libinput does) and need to interact with DRM directly. DRM support is still missing. This could be an interesting GSoC project next year 😉

The merged implementation does not support all of libinput yet. Most important touch screen support is omitted as I don’t have a touch enabled device. I plan to sit down with fellow KDE developers who have a touchscreen enabled device and implement that part together. Also I will contact the VDG to define some global touch gestures to interact with the system (I’m quite interested in having a touch gesture to activate Present Windows). There’s lots of work to be done here and I would welcome any helping hand.

Security challenges

Processing input events directly comes with a slight problem, though: one needs to be root to read the events. And that’s obviously an absolute no-go for KWin. KWin may never ever be executed with root privileges and also not an suid which drops privileges again (which also wouldn’t help in that case but so what). The application has not been designed for running as root. The same is the case for Weston and obviously I looked at how it’s solved there and there is a very neat solution to support the use case we have in logind. The session controller can ask logind to open devices and logind provides a file descriptor to the opened device. In addition logind automatically takes care to close the file descriptors when a VT switch happens, which is extremely convenient for the use cases of Wayland compositors. So obviously I went for this solution as all it needs is connecting to very few D-Bus calls. This means the libinput integration in kwin_wayland will have a runtime dependency to a logind D-Bus interface. Of course this does not affect kwin_x11, neither does it affect kwin_wayland without libinput integration, but of course without libinput you won’t get support for all features. There is one caveat though: logind will blank the VT when the session controller goes away. So make sure to not run kwin_wayland with libinput support on your primary X session. Because of that libinput support must be explicitly enabled with the –libinput command line switch of kwin_wayland.

Current state and downsides of libinput and logind

As libinput does not yet have a stable release, the dependency is still optional and it’s possible to build kwin_wayland without libinput support. This is currently very important for the non-Linux operating systems, which might want to provide kwin_wayland, as libinput only supports Linux.

I hope that libinput will become available on other platforms. At XDC during the BSD presentations I heard at least one presenter touch the topic. So I’m optimistic that in the long run this will happen as we also see that DRM and KMS is nowadays in quite a good shape on the BSDs. For KWin development it’s of course important that we have only one library to interact with. Otherwise it means platform dependent code which is hard to develop and extremely difficult to test for the main developers not using such a platform. So if you want to get kwin_wayland on non-Linux, please consider putting the energy into getting libinput working (challenge is udev) as that will help all systems and not just KWin. After all we want to stand on the shoulders of giants 😉

Logind is in a similar situation. It is developed as a component in systemd, which isn’t available on all systems which run KWin. Luckily we don’t depend on logind directly but only use a subset of a well defined D-Bus interface and that interface can be provided by other tools as well. Something like that is already being worked on for the BSD’s.
Like with libinput, I would much prefer to keep KWin lean and efficient and not complicate the code base and development by including libraries for specific platforms or having security relevant code around. As written above: using suid wrappers is very much a no-no to me. But of course it would be possible to implement the subset of the D-Bus in an independent project and provide it. KWin would happily use it, it just needs someone to write the code. So if enough people care, I’m quite sure that there will be a developer stepping up and writing the code.

I decided to put out a small FAQ here for those who have questions about the implications of the above:

FAQ

Does that mean KWin (and Plasma) depend on systemd?

No.

But it depends on logind?

No. It uses one D-Bus interface provided by logind. It doesn’t care which program is providing this D-Bus interface. It can be logind or logind-shim or the implementation being worked on for the BSDs. Even a small binary just providing the used D-Bus interfaces would work.

You should not use logind, there must be a different solution!

I’m sorry I did not find any solution which was as efficient and secure as the one provided by logind. Of course there are solutions like weston-launch, but they introduce a lot of complexity – both on the coding side and on the installation side. As such a solution would need to be suid, I’m very reluctant to the idea. We shouldn’t introduce such possible security risks, if there are better solutions available. Logind is simply providing a feature which is needed by kwin_wayland.

Does that affect KWin on X11?

No, that only affects kwin_wayland.

But there is no logind for the BSDs! So I won’t be able to run kwin_wayland on BSD systems?

Unfortunately the fact that logind is missing is least of your problems on BSD. Logind support is only needed for libinput which right now is not available on BSD. The kwin_wayland binary on BSD will not try to interact with logind. I’m sorry I don’t have a solution for the input stack on BSDs. I really hope the BSD developers can come up with a solution for this as we don’t have the resources to build a separate input solution for one platform.

How can I change KWin to not use logind?

As I noted, it is important to me that KWin is secure and that the code base is as easy to understand as possible. I don’t like the idea of having ifdefs all over the place and multiple solutions as that results in bitrot. When I pushed the libinput change it directly failed to build on the CI system as the ifdefs introduced a variation which I couldn’t test on my system. Each ifdef and each platform-specific solution increases the development and maintenance costs significantly. This means that I will only accept patches which don’t introduce the above mentioned problems. Preferrable a small wrapper binary could provide the needed D-Bus interface for KWin and other applications which need this functionality. This would not need changes in KWin at all and would be from my perspective the perfect solution.

Why won’t you implement such a wrapper binary?

Honestly there are a million things I would do if I had time, but a day has only 24 h and I have to prioritize my work. Just check the Wayland TODO list for what we all need to do to get KWin/Wayland ready. Why don’t you open your editor and get some work done? 😉

But if KWin uses logind, Slackware will drop all of KDE!

Yes, I have read that (see comments). Luckily the situation for Slackware is similar to the BSDs: it doesn’t matter right now. Slackware doesn’t provide Wayland packages yet, so the logind support won’t be used as there is no kwin_wayland binary which could be built. And if enough people care, as I said, one or more of them can write the wrapper binary and KWin and other compositors will work just fine.

How can i help?

Best by writing code 🙂 See the TODO list I linked in an above answer. Also it would be good if someone documented the steps to get kwin_wayland running and how to develop on it cough.

Posted on

Introducing KWayland

Today we released Plasma 5.1 which features a new library called KWayland. KWayland originates from KWin and got split out to allow code-reuse especially in KDE components which use LGPL instead of GPL.

Client

So what is KWayland? KWin/Wayland supports compositing to a Wayland surface instead of an X11 Window for quite some time already. For this KWin has to “talk” with a Wayland compositor. It needs to create the surface, map the rendering buffer, get input events, update the cursor image, etc. etc. In fact it’s just a normal Wayland client. The Wayland libraries have a nice callback mechanism, but it’s not very handy for Qt developers who would for example prefer getting a signal emitted instead of a static callback being invoked. So the code we had in KWin was kind of wrapping the low-level C API into a little bit higher-leverl Qt-style API.

Now after 5.0 got released we had more time to work on Wayland with the result that more developers started to look into the code and also had the need for this Qt-style API. An example is kscreen which needs a Wayland backend. In order to not duplicate work or have similar API in multiple projects, we decided to split out the code from KWin and turn it into an own library. And the result is KWayland.

So far KWayland in 5.1 provides a Qt-only (in frameworks speak tier 1) client library which wraps a limited subset of the Wayland client API (basically whatever KWin needs). It is still low-level enough that one can just combine it with the low-level C library, each instance of a class can be casted into the respective Wayland type. A lot of work went into the client library to clean it up for the first release as initially the code was never intended to be used as a library. In 5.1 it’s already used in two components: KWin and KInfoCenter. KInfoCenter has a Wayland module since 5.0 and the low-level code could completely be replaced by the library and in addition more information can be shown.

Server

But there is more in KWayland. There is also a server library which is not yet released. This server library will be used by KWin to implement the Wayland compositor. And it’s already used – not yet by KWin (though I have POC code), but by KWayland itself. It’s the backend for the auto tests. Each test case starts a dedicated Wayland server created with the server library. This is really convenient and a huge step forward compared to the situation we have on X11. It allows us to easily test both client and server API at the same time.

How does it relate to QtWayland?

QtWayland solves a different problem than KWayland. QtWayland main purpose is to be a QPA plugin. KWayland is intended for cases when the abstraction is not enough and one has to low-level interact with Wayland. Just like we have applications using X11 directly although there’s a QPA for it.

Posted on

XDC 2014

Last week I had been at the 2014 X.Org Developer’s Conference in Bordeaux, France. After Nuremberg two years ago this was my second XDC and I am very glad that I was able to attend and want to thank KDE e.V. for sponsorship. With the X.Org windowing systems (X11 and Wayland) being at the heart of KWin it is good to get an update on the latest development efforts.

Especially the talks about Wayland related topics were quite important. It was interesting to see what the Tizen developers are working on with their IVI-Shell and the discussions around the talk highlighted the need for a careful put out standardization process for the Wayland shell interfaces: if the interface does not contain enough functionality, multiple incompatible interfaces could be the result making it difficult for applications to interact with the system. On the other hand if the interfaces are too broad it will result in compositors not being able to completely implement the interface resulting again in compatability issues.

More directly touching our development were the talks concerning input handling with libinput. I already have some code prepared and expect that KWin/Wayland 5.2 will come with libinput support (more about that in a future blog post when the work is ready). The talks also showed that I need to reach out to the Krita community to get support for tablet devices. I don’t have access to such a device and even if, I would not know or understand the needs for these kind of input devices. There I will need the expertise of developers using tablet devices and I hope to find this within the Krita community.

KWin/Wayland 5.1 gained support for the fullscreen shell interface. My idea when adding this was to not have to implement DRM support in KWin, but (for the time being) leverage Weston. This simplifies development and allows us to move forward on a higher speed. Jason Ekstrand’s talk showed that the fullscreen shell provides more interesting aspects than our use case. The shell can also be used for use cases such as screen sharing: a compositor renders in addition to a fullscreen shell provided by a different compositor which can use it to e.g. capture a video stream or forward an rdp session. Very interesting and quite useful that we already support it and won’t have to add additional support for rdp into each compositor.

Last but not least I want to highlight Steve Dodier-Lazaro and Martin Peres’s talk about security in a Wayland world. They presented a solution for privileged clients which is very important for our development in the Plasma world: there will be interfaces between Plasma and KWin and nobody except Plasma should be allowed to bind to them. The library presented in this talk will solve this problem and many more. Even more the talk touched various interesting security related topics which I had never thought about in that way. For example setting a window fullscreen provides a security risk: it could fake a lock screen interface tricking the user into entering the password. On X11 the Window Manager/Compositor is unable to mitigate this risk. But on Wayland a compositor can e.g. overlay the window and explicitly ask the user whether the window is allowed to go fullscreen – compare to what browsers already do today. I’ll reach out to the VDG to come up with a good solution.

More interesting is the question on how we can trust password dialogs. This is something I already spent some thoughts about in the past. The problem right now is that a malicious application can easily trick the user into entering the password by faking a system dialog (e.g. polkit authentication or kwallet dialog). We need to find a way to show to the user that this is a trusted dialog and that the password is entered for a trusted application. A difficult task. There are many ways we can make the dialog in a way that nobody would be able to fake it: color the decoration, wobble it, put it into the Plasma’s notification area, but none of them are obvious to a user that no other process can fake it. As explained in the talk it needs an out-of-band communication channel to inform the user that this dialog is trusted. An idea which came to my mind is using KDE Connect to send a token to the connected smartphone to indicate that the dialog is secure.

Unfortunately the state of KWin/Wayland has not processed enough compared to Akademy that I could have done a talk about it. After all it was just a few weeks. So instead I decided to give a talk about what we mostly did last year: port KWin to XCB.

Posted on

An Update on kwin_wayland

With the initial release of Plasma 5.0 behind us I also started to look more in the direction of Wayland again. Now I’m kind of in full flow on Wayland work and kwin_wayland is progressing nicely. Yes, KWin 5.1 will introduce a new binary called kwin_wayland to complement the kwin_x11 binary which got introduced in KWin 5.0.

Now I do not want to list all the changes as you can hardly express them all in a blog post, but I can point to my Akademy talk. I will provide a small overview of the current state, what is new in KWin 5.0, what will be new in KWin 5.1 and where the journey is going.

I'm going to Akademy 2014

Of course there is lots of work going on and help is always appreciated. We started to use a public available task tracker on todo.kde.org. Also I have to say that there are still quite some open tasks for kdecoration2. Please help as I cannot split myself and it would be super important to release KWin 5.1 with kdecoration2.

Posted on

A KDecoration2 update

Before heading into the weekend I thought about writing a small update about the KDecoration2 status. Since my last blog post I started integrating KDecoration2 into KWin. This was partially easier and partially more difficult than anticipated. Especially ripping out the old decoration code is rather complex. There are quite some design differences which make the transition complex and especially values inside KWin core are using enums defined in the decoration API – e.g. the maximized state is kept as a KDecorationDefines::MaximizedMode. This will need further work to move the enums and so at the moment the old decoration library is still compiled although the library is no longer in use.

Ah that means there is code? Yes, today I pushed the branch as “graesslin/kdecoration2” into kde:kwin git repository. To give it a proper try you also need the kde:kdecoration (master branch) and kde:breeze also on “graesslin/kdecoration2” branch. The new decoration API is working quite well and I’m rather satisfied. The memory usage of KWin dropped significantly. In a previous report I mentioned that KWin needs around 200 MB, right now my KWin only needs around 40 MB, the number of open windows is a little bit smaller, but still it shows in the right direction. And that’s without any optimisations. There is still some optimization potential in Breeze (check out our todos, all purple tasks are in Breeze) and in KWin (red tasks). Also a nice improvement is that the window decoration no longer flickers when resizing the window. This is a rather big annoyance of KWin 5.0. I expected that the new API would fix this issue, but seeing it confirmed is really nice 🙂

Last but not least the restart of KWin got faster which is a nice improvement for KWin developers, for users it’s not that important. The reason for this is that when we enabled/disabled compositing we recreated the window decorations. So when restarting KWin we first created all windows with their decoration before enabling compositing to just destroy them and create them again (yes it would have been possible to improve it, but it doesn’t hit users). Now with the new API there is no need to recreate the decoration. Only a Renderer is exchanged, but the rendering is delayed till it’s needed.

This screen shot does not only show the new Breeze decoration, but also some new features: when quick tiling a window the borders cornering the screen edges are removed. Also in the preview application one can see that the decoration scales which is nice for high-dpi screens. The decoration API follows the approach Plasma is using.

I have been running a KWin with the new decoration API since Monday, which means we are close to start the review process. But there’s of course still work to be done and I’d appreciate any help. The window tab API is not yet implemented, the configuration module needs adjustments to load and render the new deco and most important we have to port the existing decorations like Oxygen, Aurorae, deKorator and QtCurve. For the last three I want to improve the theme experience by allowing the plugin to say that it supports themes directly in the JSON meta data and point to where to find them. So the configuration module can just show all of them. The trick will be to pass the to be used theme to the factory method (we have a nice QVariantList there which can be used). Also the meta data will make it possible to point to GHNS configuration files so that we can not only download Aurorae themes from the configuration module, but also other themes.

Posted on

KDecoration2 – The road ahead

Yesterday I blogged about why Breeze is not the default window decoration in KWin 5.0. The blog post touched a little bit the problems with our decoration API. In short: it’s QWidget based and that doesn’t fit our needs any more. It uses a QWidget as an X11 window. At the same time KWin intercepts the rendering and also input handling, redirects it and forwards it. So why use a QWidget at all? Also using a QWidget is quite a memory waste in the Qt5 world. The QWindow behind the QWidget uses a QXcbShmImage with the same size as the window. As explained in yesterdays blog post the window has the size of the managed window plus the decoration. So for a maximized window we hold an image of the size of the complete window while we just need the titlebar strip. We can do better 🙂

Our decoration API is also showing it’s age. It’s cumbersome to use, too difficult to use. In fact there is a KDecoration and a KCommonDecoration – the latter trying to make KDecoration easier to use by for example providing buttons. The API got extended several times to support more features which are all optional. The API is difficult to use from KWin side as it’s not stateful and quite often needs to call into the decoration API calling virtual methods the decoration API provider needs to implement. Last but not least it’s difficult to test new decorations as we don’t have a dedicated viewer application to test the interaction and painting. You have to kind of use KWin as the development host. Not the best solution.

The idea for a new API had been in the room for a long time. I opened a bug report for it more than two years ago. Last week I finally started with the implementation and tackled three things at the same time:

  • New decoration API
  • Viewer application
  • Breeze decoration

In the current state it looks like this:

The outer decoration is the existing Aurorae theme. It looks already quite good, but there is of course still lots of work to do. The API is not yet feature complete, it needs implementation in KWin and Breeze needs a pixel perfectionist to get it right (which I am not). And that’s where you can help! Thanks to our sysadmins we have a new todo board and I requested a project for KDecoration2 and prefilled it with very easy tasks. This is a wonderful opportunity to work on easy and new code and helping both KWin and the Visual Design Group achieving an important new step. Without your help we won’t have this in 5.1 and it would be so important for both KWin and the overall design of the Plasma desktop. So please grab the code and start hacking. Grabbing the code, where? The new decoration API can be found in the git repository kde:kdecoration, the viewer application in git repository kde:kdecoration-viewer and the new Breeze window decoration in git repository kde:breeze in branch “graesslin/kdecoration2”.

So what makes KDecoration2 better? Obviously it’s no longer QWidget or QWindow based. Instead it’s a pure QObject based API. It provides a paint method a plugin needs to implement which gets a QPainter passed into. This allows KWin to control the rendering and to render to the best suited backend for the current compositor (e.g. just a QImage or a Shm shared pixmap). Also the input handling will be controlled from the backend side by sending appropriate events to the decoration. The API takes care of all of the handling – activating the buttons forwarding title bar presses, etc. This alone makes the API hopefully much easier to use from plugin side. It also provides the base implementation for all the required buttons, so that the decoration only needs to provide the painting of the buttons. Simplified the API looks like the following:

There’s an additional singleton DecorationSettings which provides common settings for the decoration. Also there’s an additional second private API which must be implemented by a backend. This will allow us to use KDecoration2 in multiple places. I want to see it uses in KWin, but in future I’d also like to provide our decorations for QtWayland. For this I hope that KDecoration plugins can also be a solution.

Posted on

Why Breeze is not the default window decoration

This week we finally released Plasma 5.0 including KWin 5.0 and also a new design called “Breeze”. While Breeze provides a window decoration, KWin still defaults to Oxygen and that’s for a good reason. As I had been asked quite often why that’s the case and on the other side got lots of feedback from disappointed users using the Breeze decoration I think it’s needed to explain in a blog post the technical background.

I start with explaining how our window decorations work in KWin 4. KWin is a so-called re-parenting window manager. This means the managed X11 window is put into another X11 window providing the windwow frame. In KWin we use a QWidget for the window frame. Thus we are also restricted to what QWidget provides us. Our window decoration API predates the Compositing support and this adds quite some restrictions to it. Our solution is to intercept all paint events on the decoration’s QWidget and suppress it, trigger a repaint of the compositor and in the rendering pass ensure the decoration widget repaints to a temp image which then gets copied into a texture to be rendered by the Compositor.

The Breeze window decoration theme is based on the Aurorae theme engine. As I’m the main author of Aurorae I can bash it in this blog post without feeling sorry about it 🙂 Aurorae was designed to make it very easy to style a decoration and to make use of the new added translucency features. Being a solution which could be used as a default decoration was never the aim. The idea was to allow users who want the customizability this feature while the majority of the users could use the faster native themes. Aurorae was never fast and will never be fast. Over the time the performance improved, especially thanks to using QML. But also in that case it was only usable with the raster graphics system in KWin 4 times.

Now in KWin 5 the usage of QML is the main problem which makes it difficult to use Aurorae at all. QtQuick uses the SceneGraph and uses QWindow instead of QWidget. That’s quite a bummer for our QWidget based API. We adjusted the internal usage to support QWindow based decorations but that was quite a tough road as there are differences in the behavior of the windows. As it’s no longer QWidget based our interception of paint events is broken and we needed a new solution for it. And this solution is even more ugly than the old one because QtQuick is nowadays rendering through OpenGL. Due to limitations in Qt’s OpenGL implementation (might be addressed in Qt 5.4) we cannot share with the OpenGL context used by QtQuick. But we need to get the content from the Aurorae window into our OpenGL texture. The solution is to render to a QOpenGLFrameBufferObject and read it back into a QImage just to upload back to a texture. Not only is this a huge overhead to copy the content from GPU to RAM and back to GPU it’s also wasting lots of memory. The frame buffer object has the same size as the window and that’s way larger than the actual window decoration. In case of a maximized window it’s not just the title bar area but the complete window. And that overhead exists for each window.

That alone might render Aurorae completely unusable. I’m currently using the Breeze theme and KWin needs more than 200 MB of RAM – not really acceptable. But the situation is even worse. With QWindow we don’t get to know which areas got updated. So whenever e.g. a button gets updated we have to repaint the complete window including the complete copy of the decoration content. Which especially in animation situations is quite a problem.

The last problem to mention is OpenGL. QtQuick is supposed to use a dedicated rendering thread, but Qt disables that for all Mesa drivers and instead uses the main thread. But that’s also the thread KWin’s compositing OpenGL context lives in. That’s quite a performance problem and also introduces lots of instability problems (might also be addressed in Qt 5.4).

Overall the situation is so bad that colleagues recommended to disable Aurorae overall in the 5.0 release. As we released with it you can see that I disagree in that point. There is hardware where it’s working quite fine – on my system it doesn’t matter that it uses lots of RAM and if your driver supports Qt’s threaded rendering the performance problems are mostly gone and also all stability problems are gone. So the situation hasn’t changed: for users who want to customize there is a solution but it might introduce a loss of performance. But as a default theme like Breeze it’s clearly not an option.

So what’s the road forward? I started implementing a new decoration API removing the restriction of the decoration being QWidget based and at the same time I started implementing the Breeze decoration with this new API. I hope that we can introduce this in KWin 5.1. I’ll write another blog post about it soon and also prepare lots of small and easy tasks for new developers to join in this effort and help making a kick-ass decoration solution for 5.1