This week I have been at the XDC 2012 kindly hosted by SUSE in Nuremberg. It was a very useful conference for me and I’m very glad I went there. There is not much difference to a KDE conference, even the N9 density was kind of the same. Of course I was asked quite often about the current state of Wayland in KDE and I honestly replied which resulted in rather incorrect “news” postings about Wayland in KDE not happening “any time soon” (whatever that is supposed to mean) to “Wayland for KDE will be delayed” (given that we never had a schedule in the first place, it cannot be delayed).

Actually there is not much to write about as to a reader of my blog you are already aware of all the work I am currently putting into Wayland. It’s just that I never write that I do something with Wayland in mind, because I don’t want to hype the technology.

Nevertheless I had been asked recently rather often about a status update and also promised that I would write a blog post if we reach the fund raising aim for the Randa sprint (thanks a lot for the great support on the last day of the fund raising campaign). So I want to give here a general overview of all the things which need to be done for Wayland.

Porting KDE to Wayland

For a general “KDE on Wayland” we have to consider three areas:

• Applications
• Desktop Shell
• Compositor

For those we have different things which needs to be done and so I will discuss them separately.

KDE Applications on Wayland

For most KDE Applications there is not much work to be done. Thanks to the Windows and OS X ports the code is no longer platform dependent, so all which is needed is having a Wayland backend instead of an X11 backend.

This problem is solved with Qt 5. Once our applications use Qt 5 and KDE Frameworks 5 they should run fine on any Wayland compositor, e.g. Weston. Of course there are a few applications which use X11 directly (e.g. ksnapshot), those needs to be adjusted in addition or be morphed into KDE’s Wayland Compositor (that is something I expect to happen with tools like ksnapshot or klipper).

KDE Plasma

Our Plasma Desktop Shells (Desktop/Netbook/Device) need more adjustments than a normal KDE Application. Plasma is still doing quite some X11 directly for various tasks, like e.g. the tasks manager or pretty much any communication with KWin.

Before we can start working on adjusting Plasma for Wayland we need to get it to Qt 5 first and that requires KDE Frameworks 5 and that requires libplasma2. Currently our Plasma hackers are meeting in Randa thanks to your support to work on libplasma2.

Once Plasma is running on top of libplasma2 we can start working on Wayland support. How that will look like, I don’t know. It’s not a problem we can tackle right now, so it does not make much sense to think a lot of it. We know we need to change a few things here and there to make it work.

But what is really important is that we Do not want to break the desktop. Neither with going to libplasma2 nor with going to Wayland. So any fast steps do not make any sense. It’s important to get this right before giving it to the users. Wayland is an awesome technology, we all want it, we all support it and we don’t want to damage the technology by going to it too early. This has happened too often in the past (not only in KDE) that great technology got damaged because it got released too early on the users. (NOTE: with this I do not mean that Wayland is not ready yet, but that going to Wayland will cause regressions inside Plasma/KWin and there is no need to expose these to the users if we have a wonderfully working X11 backend.)

KWin

Our current planning is to make KWin our Wayland Compositor. This seems like a useful approach as that can help us having a consistent window management experience no matter whether you run on X11 or on Wayland. Even in a Wayland world we will still need to support X11, it’s not like that will go away. I expect that the Linux world will have to support X11 at least for the next 25 years, we have many legacy applications around, which still use things like Motif, so that won’t change. We have with KWin a very good X11 based window manager so it seems quite logical to me that also in a Wayland world KWin will be responsible for being the X11 based window manager.

Given that our manpower is rather limited and given that X11 is what we have right now and we do not have the resources to develop two Compositors (one for Wayland, one for X11) it seems to me that extending KWin with Wayland support is the only possible solution right now.

Now KWin is an X11 based window manager and compositor. It’s development started in a time when nobody expected that there could be anything else than X11, so you could say that it expects that all that exists is X11. This means the difficulty in porting KWin to Wayland is not in adding Wayland support to KWin, but in making it possible to have a KWin without X11 support or at least to be able to start KWin without needing an X Server.

For adding the initial Wayland support to KWin which allowed to include a window in the scene graph and pass input events to it, I only needed around three days of development (that included getting used to the new windowing system and hitting my head against a wall because I was too stupid to find the documentation and too proud to ask for help).

Current State of Porting KWin

For me it is important that going to Wayland does not decrease the code quality of KWin. I don’t want to have many if (X11) { foo(); } else if (Wayland) { bar(); } code blocks. I want to have KWin in a state that it can be easily maintained, that we are able to maintain the X11 code base even once we all run and use Wayland.

There is a git branch with some patches to have KWin support Wayland clients. If you look into the branch you will notice that it does not contain any new commits for more than a year. So it seems that nothing has happened in that area.

Well that’s not true. All the work I have put into KWin over the last year have been with Wayland in mind. I have a pretty clear plan on what needs to be done inside KWin to go to Wayland and I tend to follow that plan. I get side-tracked from time to time to improve the KWin out there right now (e.g. performance improvements) but in general I follow that master plan.

An example for that is the support for KWin Scripting. That might be surprising, what is the relationship between Scripting and Wayland? To have Scripting support I had to add Q_PROPERTIES to the class representing a window (class Toplevel) and to the class representing a managed window (class Client). This means we kind of extracted the interface of how a window needs to look like. The Client class has never be meant to be used for inheritance, so we did not know how the interface looks like. But in future we will need to have a WaylandClient and an XClient. That’s quite a change and scripting helps a lot to know how we need to make the class abstract.

Furthermore I hope that scripting helps to allow us to perform unit testing. I do want to add a unit test for each method before turning it abstract (remember that we don’t want to break the desktop) and to ensure through testing that the X11 and Wayland based implementation behaves the same from a window management perspective.

Another example of work going into Wayland to have the KWin improved right now is this bug I fixed some time ago. For the time being it means that when a window closes it is not raised on top of other windows any more. What has that to do with Wayland? The bug has been that KWin only kept track of the stacking order of Clients, but not of the more general class Toplevel. In order to go to Wayland and to be able to properly integrate Wayland Clients into our stacking order this had to change to keep track of the stacking order of Toplevels instead. It was a difficult to fix bug, but a very important change for going to Wayland.

Also the refactoring work I recently blogged about is an important step on the road towards Wayland. Especially the splitting of the OpenGL compositor is very important. This means that the actual Compositor (SceneOpenGL) does no longer depend on X11. The dependency has been moved into an OpenGLBackend with currently an GlxBackend and EglOnXBackend. This makes it much easier to add further backends in future to e.g. support KWin on top of another Wayland compositor or KWin on top of KMS through libgbm.

Personally I’m very satisfied with the progress we have made over the last year in preparing KWin for the important task of adding Wayland support. I think we are completely on schedule and the state is really looking good.

The Schedule

There is actually no schedule for the porting of KWin or KDE to Wayland. Many things like KDE Applications and KDE Plasma completely depend on the progress of Qt 5 and KDE Frameworks 5.

So what about those dates one can read about in the Internets? Well that are dates coming from my presentation at last year’s Desktop Summit. I put up there a very tough time line for the case that we could get many people involved in working on Wayland. That hasn’t happened so far. Also parts of the time line were just stupid. I wanted to have a first prototype already in KWin at the time of 4.8. It just didn’t make any sense. Wayland was still a too strong moving target and distributions did not yet include the needed libraries any way, so it did not make much sense. It would not have been anything for users and in case anyone wants really to play with it or develop it, there was the branch. As that has not happened I did not see any advantage in merging the code into master.

The second item on the time line was an idea to have Plasma Active running on Wayland rather soon, but that actually did not make any sense without Qt 5/KDE Frameworks 5. So that was really a stupid thing to put into the time line.

The third item in the time line when we actually have everything in place had a strong “It’s done, when it’s done” and “Don’t break the desktop” note. So any references on when I said when KDE will be on Wayland is just wrong. And I do hope that I have clarified this with this blog post. The times I set out where ambitious and idiotic. I do apologize for putting them up in the first place and would kindly ask anyone to realize how idiotic they have been and no longer refer to them. Thank you.

What next?

I’m personally quite satisfied with the current state of preparing KWin for Wayland and I think we have reached a point where we can seriously start thinking about adding real code specific for Wayland to KWin.

Given that we have a nicely refactored OpenGL backend I want to experiment with having KWin run on top of KMS or on top of another Wayland compositor. When I will find time for that I do not know, but given the already upcoming feature freeze it will be hard to have anything in 4.10.

Also quite some required dependencies are not there yet. Libgbm will be out with Mesa 9.0, the release of Wayland 1.0 is expected somewhen soonish and XWayland might hit the next X-Server release which will happen around March. The dependencies are rather important as we cannot depend on unreleased code in KDE. Quite a lot people would complain if KWin would depend on an unreleased X-Server. So that is clearly something to keep in mind when adding the code. Not to mention that I run Debian Testing and don’t like building everything from code.