A circle closes…

At Desktop Summit 2011 in Berlin I did my first presentation on Wayland and presented the idea of Wayland to the KDE community and explained to the KDE community how we are going to port to Wayland. This year at QtCon in Berlin I was finally able to tell the KDE community that the port is finished and that our code is ready for testing.

In 2011 I used a half hour slot to mostly present the differences between X11 and Wayland and why we want Wayland. In addition I presented some of the to be expected porting steps and what we will have in the end. This year I only used a 10 min lightning talk slot to give the community an update on the work done the last year.

(Watch video on youtube, my talk starts at 15:04)

Of course the work on Wayland is not yet finished and Wayland is not yet fully ready for use. There are missing features and there must be bugs (new code base, etc.). But we are in a state to start the public beta.

What is interesting is comparing the slides from 2011 to what we have achieved. The plan presented there is to introduce “Window Manager Backends” in KWin. We wanted to identify windowing system independent areas and make our two most important classes Toplevel and Workspace X11 free and add a window manager abstraction. During the port this wasn’t really an aim, nevertheless we got there. We do have a window manager abstraction which would allow to add support for further windowing systems. Toplevel is (at runtime) X free. Workspace, though, is not yet X free, but that moved on my todo list.

Also we thoughts back in 2011 that this might be interesting for other platforms naming Android, WebOS and Microsoft Windows as examples. Android we kind of achieved by having support for Android’s hwcomposer and being able to run Wayland on top of an Android stack. Support for Android’s surfaceflinger is something we do not aim for. The example of WebOS doesn’t really fit any more as WebOS uses Wayland nowadays. And Windows is only in the area of theoretically possible (though with the new Linux support it would be interesting to try to get KWin running on it).

KWin nowadays has a platform abstraction and multiple platform plugins. This allows us to start a Wayland compositor on various software stacks. Currently we support:

  • DRM
  • fbdev
  • hwcomposer (through libhybris)
  • Wayland (nested)
  • X11 (nested)
  • virtual

Adding support for a new platform is quite straight forward and doesn’t need a lot of code. The main tasks of a Platform is to create the OpenGL context for the compositor and to present each frame on the Platform specific output. All platforms together are less than 10000 lines of code (cloc) and a single platform is around 400-3000 lines of code.

In order to add support for a new windowing system more work would be needed. It is very difficult to estimate how much code would be needed as it all depends on how well the concept can be mapped to Wayland. Ideally adding support for a new windowing system would be done by creating an external application which maps the windowing system to Wayland. Just like XWayland maps X11 to Wayland. But as we can see with XWayland this might not be enough. KWin also needs to be an X11 window manager to fully support X11 applications. Given that it really depends on the windowing system how much work is needed.

One could also add a new windowing system the same way as we added support for Wayland. This would require to implement our AbstractClient to have a representation for a managed window of the windowing system and add support for creating a texture from the window content. In addition various places in KWin need to be adjusted to also consider these windows. Not a trivial task and going through a mapping to Wayland is always the better solution. But still it’s possible and this makes KWin future proof for possible other windowing systems. In general KWin doesn’t care any more about the windowing system of a window. We can have X11 windows on Wayland and Wayland windows on X11 (only experimental branch, not yet merged).

This brings me back to my presentation from 2011. Back then we expected to have three phases of development. The first phase adding Wayland support to the existing X11 base. That was what we experimented with back then and as I just wrote still experiment with it. As it turned out that was not the proper approach for development.

As a second phase we expected to remove X and have a Wayland only system. At the moment we still require XWayland to start KWin/Wayland. During the development it showed that this is not something really needed. It was easier to move the existing X11 code to interact through XWayland – we could keep the X code and move faster.


The third and final phase was about adding back XWayland support, so that KWin can support both X11 and Wayland windows. That’s the phase we developed directly. Which is kind of interesting that we went to the final step although we thought we need easier intermediate steps.

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.

Akademy Impressions

Yesterday evening I returned from this years Akademy which means that today is a perfect time to reflect some of the impressions.

Overall I think this was one of the best Akademies I have attended so far. The atmosphere was just great, the location was overall quite good and the weather was awesome.

Akademy started for me at Friday with the AGM of the KDE e.V. It was a very interesting AGM. I think it was a good decision to move the AGM to Friday and hope that also next year will be like this. If you are interested in more about the AGM, just read Mirko’s blog post. A small reminder: if you are a supporting member of KDE e.V. you are allowed to join the AGM, but without voting rights.

On Saturday and Sunday we had the conference with the talks. I myself had 1.3 talks – the Quality talk I shared with David and Vishesh. Once the recordings are available I recommend to watch it as it also addresses the shorter release cycle discussion and why I think that this would improve our quality. Speaking about the shorter release cycle: we had a very constructive BoF later the week and I think we found a very good compromise to move forward.

The keynotes were overall quite good, I was especially interested in the Jolla keynote. But also Kevin’s keynote about the KDE democracy is worth watching. Quite interesting was the discussion about “Respect the elders” and what makes up a KDE project. That we discussed that the Linux kernel could not be a KDE project because of their bad mailing list communication skills is quite a saying. As if we would have known that LKML would become a big topic a few days later.

The most interesting talks from my perspective were of cause the technical ones. I really enjoyed Volker’s expression template talk covering the topic of implementing domain specific languages with the help of C++ meta programming. Also Milian’s talk about improving the performance of C++ is something you should watch if your application is critical (also if not). KWin already gained the first improvements thanks to this discussion. And more will follow.

The conference ended with the Akademy Award ceremony. I am quite happy with the decision the jury took – especially given that I thought about two of the winners last year when I was a member of the jury. So to say we chose a good jury last year ­čśë

What made me really happy at this years Akademy is that we are broadening our scope. This year we had talks about Mer and Razor Qt and like last year members of the VideoLAN project were around. And of course there was the Qt Contributor Summit co-hosted on Monday and Tuesday – though I did not attend any discussions.

Instead I spent most of Monday at the Kubuntu BoF and tried to give some useful feedback from an upstream perspective. And also of course my personal opinion like I would love to see Debian KDE and Kubuntu packagers to work more closely together. During this BoF we got an overview of the LiMux project of the city of Munich. It’s great to hear that we will soon have 15.000 KDE SC 4.11 installations, but this will take some more time – enterprise setups move rather slowly compared to us ­čśë

On Wednesday we had the release cycle BoF. I think the outcome is really good and I hope that the community agrees to trying this out. So far the discussion had been very positive and I am really happy that we can get in all the stakeholders. That distributions can share their opinion just as an equal is quite a positive sign that the communication between upstream and downstream is really good in KDE. In fact for quite many distributions I am not able to say if a developer belongs more to KDE or more to the distribution.

In the afternoon we had the day trip to the sea side. Thanks to that I can check the box for “swim in sea once a year” for 2013. In the evening we had a wonderful meal before heading back to the hostel.

On Thursday we had a Bof on Plasma Active, but apart from that I did not attend any further BoFs as I had to head to the airport in the late afternoon. Travel back was quite smooth and way better than the travel to Akademy. I almost missed my flight because the 30 min travel from Mannheim to Frankfurt Airport took 90 min with Deutsche Bahn. On the positive side I did not have to wait for the security check ­čśë

Looking forward to next years Akademy wherever it will be.

Akademy Impressions

Now that I am back home I finally find some time to blog about my impressions of Akademy this year. Overall it was a really great Akademy at an awesome location and wonderfully organized by the local team. Thanks a lot for your work!

For me it was the already the fifth Akademy – I hadn’t realize that before and was quite surprised, I still remember my first Akademy in Mechelen as it were yesterday. This year Akademy was a very special one as I had been a member of the jury for the Akademy Awards. I am very happy with the people and products we awarded this year. Camilla, Lydia, Kevin and Nicol├ís all do an awesome job in their area and all help shaping the future of KDE.

From a conference point of view my personal highlights were the talks about Qt 5 and Frameworks 5 (thanks to Thiago, Kevin and David) as well as Mirko’s talk and the talk about defensive publications. I’ll probably start to document some of the “innovations” inside KWin soon (personally I do not consider anything inside KWin being an innovation, but I see that we should have it published before someone gets a patent on what we did years ago).

My highlight of the days after the conference is the training on QtQuick 2 by our friends from KDAB. I was afraid that I would not learn anything new, but there was lots I did not know and I realized how I can improve my QML code quite a bit. Some of that (especially based on feedback from Nuno) already made it into the 4.9 release. But maybe most important is that I got an idea how QML based effects could look like which could contain shader elements as will be available in QtQuick 2.

While nothing is implemented yet I thought about how our Fade effect could look like in QML:

WindowEffect {
    id: myWindow
    opacity: 0.0
    onClosed: opacity = 0.0
    Component.onCompleted: myWindow.opacity = 1.0
    Behavior on opacity {
        NumberAnimation { duration: 150 }

Well we will see how this idea will evolve.

Another highlight of the days after the conference was a session where Jeroen van Meeuwen was present and explained his plans for our bugtracker. I am very glad that there is someone who cares and wants to help us getting bugs.kde.org in a usable shape again. I am really looking forward to this happening and I hope that our developers will support his efforts and start using the bugtracker. I am convinced that bugzilla is our most important and most neglected piece of architecture and a proper usage will help us producing better products (and with that I don’t mean that we fix bugs).

Of course I hardly did any coding, but I mentored a BoF where I explained a little bit about the internals of KWin. I hope to see some patches and that is more important than me coding. But I fixed a few bugs I found by pure chance. And I must say this makes me rather unhappy. If a functionality is broken for almost a year and it’s me noticing then something is really broken. That I don’t use the functionality, that’s just fine. But that no user noticed that the logout effect has not been working at all in 4.8 is quite shocking.

So please my dear users: if you see some “obvious” bug where you think it must have already been reported, please report it nevertheless. Not each obvious bug might be obvious to the developers (I only suspend my system and over the last year got only logged-out by a freezing BLOB). I rather have a duplicate too many than a broken feature.

That reminds me: we currently have a release candidate out. Get it, test it!