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.
Very nice and deep explanation (as always) about the Wayland/X11 stuff.
Martin, you rock!! xD
It is worth mentioning that the first piece of wayland people will experience is probably the system compositor, *not* the session compositor.
Do you know what Wayland will mean for windows decorations? I watched https://www.youtube.com/watch?v=L8zwnqKysfI and what I gathered from the talk was “Look, when we use the totally useless feature to rotate single windows, the boundary between window content and decoration is smooth and not jagged as it would be in X”.
The presentation also showed that for the enormous benefit to have a single line of anti-aliased pixels the downsides will be (or so I understand which is why ask you as the local expert here 🙂 ):
a) Every application will define its own decoration, therefore everything will look inconsistent.
b) Hanging applications lose all benefits of the current title bar (mouse hover effects on buttons, ability to resize, minimize,…)
Is that right? Is there any work to remedy that?
that was about Weston. I plan to support server side decorations in KWin. My main concern is inconsistency, I fear that GTK windows will look different than Qt windows and that’s something we should try to prevent IMHO.
Ok, so if applications used the server side decorations from KWin, would they still have those same decorations when I use another compositor like E17 while Gtk applications would have Gtk decorations and so on? (would be okay with me since the applications would look consistent in themselves which is not the case if their decorations don’t match the rest of the window)
Thi si the most elaborate and technically complex post I’ve ever seen from you Martin. While not related to the post topic, how many years did it take you to evolve from the “first patch” to the current skills and knowledge?
Re Wayland: do you know if Wayland will bring us reliably perfect KWin animations, as seen in Mac OS X, with no perceived “choppiness” that we can observe atm with the X Server?
Are you maybe experiencing some problems with graphics driver?
I understand it’s really all a matter of perception but kwin effects looks smooth on my machines (a pc with a discrete nvidia and a first generation netbook)
animations should become better, though X is not the only one to blaim.
Hi Martin,
It’s always a pleasure to read your post.
Thousands thanks for yours explanations and, of course, for your work.
Hi,
thanks for the explanations, now everything makes a lot more sense and it also shows that the news articles were just stupid.
There is one question about Wayland however which bothers me. Maybe I didn’t understand parts of it or there is something which I don’t see…
Once we are all using Wayland as the display server, what happens if the display drivers do not support OpenGL (ES, or whatever by that time will be necessary)?
That’s quite often the case if one buys a new card for which the open source drivers don’t provide 3D acceleration yet.
Is there a 2D fallback mode like there is now for KWin under X11?
Can compositing turned off temporarily, like it can be done in KWin right now (which sometimes makes sense, i.e. for running games)?
Or would a (gallium?) sw renderer be used, which might really suck regarding the performance?
Keep up the good work. 😉
I think it’s too early to discuss such problems and to be honest: it’s a corner case. For most hardware the drivers are around before the hardware is released.
Is that really the case?
At least for the radeon driver, it rather looks like the driver is lacking behind the hardware release by quarter to half a year.
So it might be true, when relying on the proprietary drivers, but maybe this route is a nogo for quite a few people?
I for instance don’t want either the proprietary amd drivers nor the nvidia drivers on my linux computer anymore and solely rely on open source drivers.
(Of course for me, this is not so much of a problem since I have a look at the support tables first.)
The second thing is, that it might as well be that OpenGL support for the hardware is available, but only in git master of mesa. Since mesa releases don’t happen that often, and since most distributions do not apply mesa updates within a distribution cycle, quite some time might pass by until the hardware is supported within the distribution.
Of course it depends on the specific distribution, but I think it would be normal to assume a delay of at least half a year for the most common distributions.
Overall, there has to be some kind of fallback route for wayland, or is that not the case?
I just fail to see what direction that might be. Just spawning an X server, if OpenGL is not available?
starting an X server might be a solution, using llvmpipe might be a solution, getting the drivers faster into the distros might be a solution (that’s my preferred one).
Thanks a lot for this detailed update – I really love reading such technical posts, and Wayland is a quite exciting technology 🙂
I do have one totally Wayland-unrelated question: You mentioned you are using Debian Testing. Which KDE version do you use? Currently I am experimenting with a self-compiled KDE put in quite hacked-together deb packages by a handwritten script as Debian often takes a while for KDE updates to reach testing. That’s working fine, but it’s also more maintenance work than just using the Debian-provided KDE. Considering we are in the freeze, however, I do not expect major KDE upgrades (like KDE 4.9) to hit testing anytime soon.
my KDE is compiled from master through kdesrc-build
Great work! 🙂
Thanks for this news. I was wondering how it is going on that front, seeing you were most likely into performance lately – no news (basically) for a year after the DesktopSummit in Berlin 2011.
I see the need to port to Qt5 and libplasma2. I still hope that there will be an experimental version to play with some time in the next few years. I don’t expect it would be hard to implement ksnapshot for wayland, same about klipper. More interesting will be making them “cross-platform”, so X and Wayland, since they were designed as kwin with only X in mind.
For the documentation – I think the wayland guys learned it’s needed, it’s now linked on their webpage :). And even pretty impressive for .. quite a short codebase.
And by the way, X11 may not be perfect (especially development whise, and wayland could improve performance), but it’s still doing a good job after so many years. Can’t really complain there, so there is no rush. Still, it’s interesting to see the progress done.
Forgot: Thanks for the effort all you guys put in there 🙂 ..