Ever since a certain free software company decided to no longer be part of the larger ecosystem, I have seen lots of strange news postings whenever one of the KDE workspace developers mentioned the word “Wayland”. Very often it goes in the direction of “KDE is now also going on Wayland”. Every time I read something like that, I’m really surprised.
For me Wayland support has been the primary goal I have been working on over the last two years. This doesn’t mean that there is actual code for supporting Wayland (there is – the first commit for Wayland support in our git repositories is from June 11, 2011 (!)).
The Wayland research projects two years ago had been extremely important for the further development of KWin since then. First of all it showed that adding support for Wayland surfaces inside KWin’s compositor is rather trivial. Especially our effect system did not care at all about X11 or Wayland windows. So this is not going to be a difficult issue.
The more important result from this research project was that it’s impossible to work against an always changing target. At that time Wayland had not yet seen the 1.0 release, so the API was changing. Our code broke and needed adjustments for the changing API. It also meant that we could not merge the work into our master branch (distributions would kill us), we needed to be on a different branch for development. Tracking one heavily changing project is difficult enough, but also KWin itself is changing a lot. So the work needed to be on top of two moving targets – it didn’t work and the branch ended in the to be expected state. Now with Wayland 1.0 and 1.1 releases the situation changed completely.
The next lesson we learned from that research project was that the window manager part is not up to the task of becoming a Wayland compositor. It was designed as an X11 window manager and the possibility that there would not be X11 had never been considered. We started to split out functionality from the core window manager interface to have smaller units and to be able to add abstractions, where needed, to support in future more than just X11. That had been a huge task and is still ongoing and it comes with quite some nice side-effects like the rewrite of KWin scripting (helped to identify the interface of a managed Client inside KWin), the possibility to run KWin with OpenGL on EGL since 4.10, the new screen edge system in 4.11 and many many more. All these changes were implemented either directly or indirectly with Wayland in mind. That means we have been working on it for quite some time even if it is not visible in the code.
My initial plannings for adding Wayland support around October/November last year was to start hacking on it in January. I was so confident about it that I considered to submit a talk for FOSDEM which would demo KWin running on Wayland. In the end I decided against it as it would have meant working on some of our very important foundations under time pressure, which I don’t think is good for maintainability of the code base.
In December though I decided to adjust my plans and focus first on the Qt 5 port as that would allow us to use the Qt Wayland bindings which are a little bit more convenient for usage in a Qt based application than the native C library. This is not something I just come up with, I discussed this small adjustment with a few people (for example Aaron Seigo) at the Qt dev days last year.
On January, 22nd 2013 sebas outlined the time line for the transition to Qt 5 and Wayland of the KDE Plasma Workspaces. It clearly states that KWin will become a Wayland compositor and that this is a target we are working on with a clearly defined time line.
Given that I am really surprised to see media writing again and again that we started to work on Wayland because other projects deciding against or for Wayland. It’s not something we decided on recently and it is quite clear that our work does not depend on any decisions or announcements our competitors do. We are an independent project, which does it’s own decisions for long term planning. The fact that our work now shifts towards Wayland just at the time our competitors decide for or against Wayland is pure coincidence.
Last week we had a Plasma developer sprint in Nuremberg (thanks to SUSE) and of course Wayland was an important topic for discussion. We had many points on the agenda. After all it’s the first sprint for us since we work on Plasma Workspaces 2 and it is needed to define our direction for the next year. Given all that I wrote so far it’s rather obvious that we would have discussed Wayland even if a certain project would not have done a certain announcement. Some topics on the agenda were based on discussions we had on the mailing list before the certain announcement was made (I’m currently sitting in a train with not sufficient Internet connection so I cannot look up the reference). Which also shows that we had long term plans which were decided on long before the ecosystem shifted.
Summary: we had been working on Wayland for years and it is our long term strategy. Our strategy is of course not based on any announcements of our competitors. We of course need to evaluate new solutions available in the ecosystem when they come up. As I already pointed out in the past, this is not yet possible at the moment and all we can see so far is that Wayland is a better solution for our needs in the KDE Plasma Workspaces than other windowing systems which might be tailored towards the needs of our competitor’s desktop shell. One of the advantage of free software projects is that the development and discussions are open and that it’s quite easy to reach out to the developers and architects of the software.
40 Replies to “The History on Wayland Support inside KWin”
I’ve read some of those “news” myself.
I came to the consideration that those that wrote this things were following only the Gnome community…
Please don’t suggest GNOME responded towards Canonical/Mir. Same position as KDE. It is perhaps cool to dislike GNOME or something, but I don’t think it is.
Which doesn’t make much sense either, since the Gnome guys are in much the same situation, having been working on Wayland support pretty much since the Wayland project started. Last I saw, they were making pretty good progress on application porting, but still a long way short on the desktop itself (Shell, Mutter).
‘The fact that our work now shifts towards Wayland just at the time our competitors decide for or against Wayland is pure coincidence.’
I don’t really agree with that statement, I’d say that as you mentioned the fact that wayland has now reached 1.0 and has stablised is a reason why lots projects are now making active rather than preparatory steps towards it.
I think the work you’ve done to get the kwin code ready for this will mean that the road to wayland for kwin will be a lot smoother than it would otherwise have been.
Many of those stating the competition is what’s driving the activity are saying this out of confirmation bias. They don’t want to think their favorite thing is causing a problem, so they flip the argument and say it’s actually improving the situation for everybody. However, I think it’s important to take your point into consideration- we need to stick to our long-term goals, or we won’t get anything meaningful done. The community can’t grow dependent on a single vendor for their roadmap.
I think competition in this situation is OK and it’s desperately needed!
Why do i think that?
Mainly because Wayland efforts started 5 years back if i am correct (half decade) and the only real life experiments end users can use are in the range of RebeccaBlackOS!
RebeccaBlackOS yes you heard it right. Then there is our beloved Xorg or X11 protocol and it seems for years now everybody agrees Wayland is the next protocol that will replace X11 but time goes by and X11 protocol is still here as the only sane option to use and the same people agreeing Wayland is replacement for X11 that everybody should use in the future are saying X11 isn’t going anywhere.
And it isn’t that much is true X11 position is the same it was 5 years ago. It has no real competition just like it was 5 years ago.
If Canonical can produce something that end user can actually use and consider replacement for X11 by the end of the year then Martin you have to agree they did what somebody sooner or later would have to do?
We have to stop thinking about X11 and start pushing the next big thing not 5 years from now but by the end of these year or at least in 2014 something has to be pushed to end users? Or what are we waiting for?
P.S. Thanks for all your hard work and i like Wayland and i hope i will be able to use it soon!
Why does a next-big-thing have to be pushed on end-users at all?
As I understand it, KWin is intended to *support* Wayland, so end users can choose whether to use Wayland or Xorg.
And never change a running system: Xorg works, and nowadays it works much better than 10 years ago (for example with autodetection: in most cases there actually is no need to have an xorg.conf anymore!).
So I do not need the next big thing. What I need is work on what we have – and working on stuff which might be better. And if the next big thing breaks things I use, then I don’t want it pushed in my face.
This is exactly why i wrote what i wrote.
1.) Everybody that works with X11 agrees X11 should be replaced with something more modern and it was decided Wayland is it! This already happened in the past!
2.) Now the same folk is acting like X11 isn’t going anywhere.
Please STOP with this hesitation and push the W thingy to end users by the end of 2014 beginning the transition now in 2013.
I mean no disrespect to the X people who are modern day alchamists. But one of tthe reasons that X is working a lot better is that we use a lot less of it.
We shouldn’t be sentimental because this only hurts everybody and some fake loyalty to X11 in this times when it was decided Wayland is successor won’t help X11 in any meaningful way.
For example “Good bye Notifications” efforts should be ditched and the only real effort for the next year or two is fixing outstanding bugs and transition to Wayland. Every change log in this and next year should have majority of lines dedicated to implementing Wayland support and making it work great.
The focus should shift completely to Wayland everything else should not waste more than 20% of available time.
err no, clearly no. That doesn’t make any sense. Let’s take the notifications as an example. How much would it have improved the Wayland porting to not do it? None. Because I was doing that as a stupidity work during discussions. In fact it’s more likely that this even helps the porting as it simplifies the code.
We decided years ago that we got a way of parallel development/improvement and Wayland development in parallel. Switching that development scheme doesn’t make any sense. As written in this blog post: we don’t change our development model each other day.
Also most of the work we currently put into KWin benefit Wayland directly or indirectly. Scripting on the first look has nothing to do with Wayland, hasn’t it? But I completely and only implemented it for Wayland. Rewriting screen edge handling on X11 has nothing to do with Wayland, has it? But in fact the new architecture is in place to allow a Wayland addition.
So no, the pace we go is right and we will continue the conservative road and not push it down to the users – not before we are ready. One 4.0 and one PulseAudio transition is enough for a life time.
I don’t know if i agree:
“One 4.0 and one PulseAudio transition is enough for a life time.”
Sure it was thought at the beginning but it was done and now is OK. PA is something i like to use for years now for example and it was way beyond the point it worked great for me some naggers was still saying it sucks. It didn’t. KDE 4 at beginning was buggy and unstable that much is true but situation stabilized and i heard somebody will be making/packaging KDE as “KDE light” variant and i was always thinking how much i would like to use something like that and paired with Wayland i do imagine that would be nice pair to use.
“We decided years ago that we got a way of parallel development/improvement and Wayland development in parallel. Switching that development scheme doesn’t make any sense.”
It does. Current one doesn’t work. Too much effort is wasted on something it was decided will be replaced. It’s like F1 team would work on the car it raced with last season and the current one would not be competitive at all.
“So no, the pace we go is right and we will continue the conservative road and not push it down to the users – not before we are ready.”
But we were waiting for it yesterday. We don’t want to use RebeccaBlackOS anymore. We want to test/use it on Ubuntu, Fedora, Arch… We want to have the possibility to use KDE on Wayland with FOSS drivers if we choose this. We don’t want to waste another few years doing nothing.
See it like that: I have been working on Wayland for years. Any new features in KWin are just nice side effects. Completely focussing on Wayland wouldn’t change a thing. If you want to get it faster: open your IDE and start hacking. If you don’t want to do that, please accept that we find our own solutions.
It’s not if i want to or not because not everybody is good at everything.
That said it looks like i am looking forward to Mir. I know a lot of work from Wayland and Xorg is being reused in Mir and i was excited for years about Wayland but RebeccaBlackOS is not something that works for me anymore at least on my Intel notebook where i was expecting i would be able to use Wayland on Ubuntu by now in some form but with the current pace i doubt we are halfway there and i just can’t watch this anymore how everybody is agreeing W thingy is desperately successor of X11 but at the same time acting like where is the rush we are happy with the things the way they are.
It’s a long shot and i am not sure if Canonical will be able to pull this off but if they do at least i will have something on my desktop box by the end of 2014 that call itself Xorg successor.
I don’t understand why you need to run something different than X. X is just fine for most things on the desktop nowadays.
Raw performance and ease of use.
Wayland does not intend to provide network transparency. Not too small parts of my workflow depends on being able to run remote applications from a simple SSH session. And the same is true for many of my co-workers.
And I’m sure that’s not the only feature which would get lost by dumping Xorg.
I don’t have anything against being able to use Wayland. But if you want to convince people to dump age-proven Xorg, please stop. You would create huge collateral damage with only little actual gain over just doing both. Because all the Xorg support code is already there.
It’s like the deadly rewrite: At some point you’ll want to rewrite your whole program. It’s very likely that that rewrite would kill your program.
There is a video on the net but i can’t remember the title and in there it’s explained how much of “network transparency” there really is in Xorg these days…
Being able to see something remotely wont go away with successor of X11.
X11 isn’t the only protocol enabling this and Xorg on top of Wayland/Mir will still be one option.
Anyway as i said looking forward to Mir and i hope Canonical can pull it off.
Firstoff it holds the promise of breaking stuff.
I don’t mind that as long as the old ways still stay available.
If they are removed, I mind it a lot (similarly for udev and systemd).
It’s interesting to read that you call Canonical a competitor. In which way do they compete with KDE at all?
where did I mention Canonical in my blog post?
It was (once more) phoronix, that spreads such nice interpretation…
I don’t need Phoronix to interpret an article.Things like “…other windowing systems which might be tailored towards the needs of our competitor’s desktop shell.” don’t leave too much room for interpretation.
What is the point of hiding the name of the mysterious competitor?
I got your point, KDE is an independend entity with own plans which are not thrown away because of some announcements. But it just feels like the whole transition to Wayland is speeding up since some announcement of some company. 😉
I decided for writing the blog post that way to make it even more clear that it absolutely does not matter to us what some companies do. Our development speed for Wayland is completely unaffected by any decisions of competitors. It does not matter who the competitor is, it could be anyone, it just doesn’t matter to us. And if you think that everywhere where I wrote about competitor it means Canonical: that’s not the case.
How about in your first sentence.
no, it doesn’t mention Canonical.
It’s a matter of fact that Cannonical abandoned Wayland, the larget ecosystem path, to create its own way with Mir. Nothing wrong with the first paragraph IMO.
5 years have already gone with almost nothing usable is too much, too long, and nothing is happening, really. What do you mean by “in the long run”? Too vague and, as such, too much wrong, as no one really knows what the undefined long run, if it derives from careless laissez-fair or “something I’ll do if I’ll have time to”, will bring, and until there many other things will happen on the display stack and by the time wayland should be ready it will be already dead! Being clever doesn’t mean being smart, and it would be smart to open a door to Mir.
P.S Nice pic, that of “Elevador da Glória” in Restauradores square.
wtf? Have you read my post and understood the part about “we need to refactor the window manager to support more than X11”? The door is open for Mir, just we won’t work on it as there is nothing available to work with. If I match my time line for Wayland support against the one of “when Mir will be ready” I see a little problem: we will have Wayland support before Mir will be ready. So I understand you correctly that five years is too long and because of that we should wait seven years? Right?
> 5 years have already gone
false. wayland was started being considered a serious approach to replace X11 since end 2010, early 2011 – before it was Kristians spare time project, you know, “fun to play around with because X11 sucks”
> with almost nothing usable
false. wayland 1.1 was just announced. weston is a usable compositor/shell
> is too much, too long, and nothing is happening, really.
yes. unfortunately deductions out of false claims are worth nothing.
> What do you mean by “in the long run”?
false, Martin didn’t say that at all. Said “We are an independent project, which does it’s own decisions for long term planning.”
If you don’t understand that, get a dictionary. But it means “we don’t decide this or that depending on our mood de toujours” (you know, much unlike canonical, who really like to jump into and out of things faster than their underwear)
> Too vague and, as such, too much wrong, as no one …
blabla, once more: “yes. unfortunately deductions out of false claims are worth nothing.”
> and by the time wayland should be ready
What exactly do you mean by “should be ready”?
Wayland is a protocol. The protocol has seen 2 stable releases now (meaning: reliable and persistent interface)
By that either wayland /is/ ready or not even X11 is “ready” (in terms of “never gonna be touched again”)
> it will be already dead!
So says your magic eightball?
> Being clever doesn’t mean being smart
Being huge doesn’t mean being tall – the question is what “what’s the meaning of that”
> and it would be smart to open a door to Mir.
And if you should fill that with a real action suggestion it would be “give yourself into the faith on the promise of what we don’t even know what it will be”?
Here’s a clever hint for a smart boy, maybe a smart hint for a clever girl – i don’t know:
Next time you want to say sth., stay with things you at least remotely know about and say sth. like “I believe canonical is great!”
Prevents you from appearing as a complete fool by telling bullshit in each and every sub-sentence of your speech.
From wikipedia at
“Original author(s) Kristian Høgsberg
Initial release 2008
Stable release 1.1 / 15 April 2013; 7 days ago
Development status Officially released
Written in C
Operating system Linux
Type Display server
So, do the simple arithmetics and count the number of years.
“Wayland is intended as a simpler replacement for X”
Five years later, this doesn’t hold true.
Wikipedia is not always right. The initial commit is not the same as the initial release. The operating system information also looks pretty wrong. And especially I like “KWin is capable of running under Wayland since” and there it stops. Well Wikipedia is not always the best place to prove one’s point.
Martin, I agree wikipedia may be inconsistent and slack in many areas, but it seems to me that the project starting date is correct, if you dig it through a search engine. Kindly refer to
Anyway, you already clarified the “refactoring” as a … well, “a door not closed”, which was not clear to me, when taking in context your former post “war is peace”, and in particular the statement “Third question: Will KWin support Mir? No”
But it’s not written as initial release (whatever is meant with that). Let’s consider that for Mir, what would be the reference date as with Wayland? This year or the nine month of in house development before? If you add the nine month of in house development it will also be three years till the first real release. Add the two years delay which are common in software development and we have also five years.
Don’t take this one sentence out of context. It was the introduction to the section that we in general do not accept distro specific patches. As long as Mir is an Ubuntu only solution, there is no chance for Mir support in KWin to ever be merged (let’s just face it: I don’t know of a KDE workspace developer using Ubuntu). The door has never been closed, but it’s very unlikely that any other distribution (which isn’t an Ubuntu fork) will pick up on it and I don’t see where developers would come from to work on integration in KDE. I don’t see how our CI system would be able to support it as it’s not on Ubuntu, I don’t see what advantage it would add given that we want to use the Wayland protocol for anything new. I don’t see how KDE developers would be able to adjust the system to our needs given that it’s under CLA. I don’t see how anybody would be willing to fork it, to keep up development in case Ubuntu fails given it’s rather strange licencing choice. I could continue like that for days. As you see I evaluated quite a bit about the non-technical aspects we need to consider. I don’t want to go into the technical details as that’s too early.
Martni, you got me on your side; I fully agree with you. And frankly speaking, I can’t see Ubuntu sheeping with Mir for the desktop from one year now; For for a restricted set of tablets and whateverr android devices they’re targeting, well, after all they still have components from Android to “Shell-ize” upon. But not in the desktop.
Is it really so hard to read?
> wayland was started being considered a serious approach to replace X11 since end 2010, early 2011 – before it was Kristians spare time project, you know, “fun to play around with because X11 sucks”
That Kristian started toying on it in his spare time in 2008 (as the article btw. mentions, apparently you don’t even read your surface-level references) does NOT mean: “this is gonna be the next linux display server”
If you’d new the *least* bit about display server history, you’d know how to weight these things (there’s been half a dozen “next display servers replacin X11” approaches in the last ten years – all failed)
Shuttleworth btw. announced wayland support for ubuntu *before anyone else* in Nov. 2010 – not that canonical did even the least to make that happen… but it’s more or less the earliest statement that “this is could be serious”
And I’ll say it again, you’re working on Wayland :D.
Anyway, the “news” was most likely that either KDE and Gnome decided against Mir, and for Wayland for their desktop shell as both see no real advantage using Mir.
As an application developer I basically don’t care and don’t understand the fuzz. Okay, for Desktop Shells, there is a huge impact, so you and the Gnome guys had to do a decision – but a decision we application developers (mostly) don’t care about.
Most important will be that GTK+ and Qt work upon Wayland and Mir, and if we are game developers that the engine supports it. If not, ok, I can’t target something, but I’m positive that this will be done in the libraries and engines, and I won’t have to care about it.
No, at least KDE did not decide against Mir, because it’s not possible to decide for or against it at the moment. Whether Mir will ever see a functional release is not known at this moment. So there is nothing to decide on. That’s exactly what I expressed in my first post on the topic. We can talk about whether we have to decide for or against Mir once there is a release and it’s as awesome as it was promised to be.
My bad, i thought they already had some final specification and release. Was bad informed on that one, thanks for correcting.
Comments are closed.