The next Kubuntu Graphics Stack

One of the things that we have been discussing at length in the past few months is the graphics stack in Kubuntu, and how we’re working towards having Plasma Workspaces 2 running on top of Kubuntu-next and Kubuntu-next-next(-next). In this article, I will explain the strategy we have laid out for a smooth transition.

2013: 4.11 atop XOrg

For Kubuntu-next (13.10), the answer is pretty easy: We’ll be relying on plain old Xorg. End of story. Alternatives do not provide us any benefits, so instead of jumping onto an unproven and at the time of writing buggy new technology stack, 13.10 will present you a stable and proven solution as to the display server, and on top of that provide a KDE SC 4.11 with all the performance improvements that we have worked on in the past months. They will, on many systems be quite impressive. The port to XCB provides a whole slew of advantages, and we have reduced memory consumption significantly in many components, Kontact for example.

Later this year, we’ll make the first test packages of Plasma Workspaces 2 available, which is the upcoming version of Plasma, based on Qt5 and an entirely hardware-accelerated graphics stack. Do not expect them to be much useful at that point, however, as Plasma 2 (and the underlying Frameworks 5) is still a fast-moving target. The packages are mainly useful to catch integration problems early on, such as co-installability of KDE SC 4 and Frameworks 5 packages. Later on be able to run a KDE SC 4 application atop a Plasma Workspaces 2 — mixing and matching whatever is stable and mature enough for you. This eases the transition for our users and makes it a lot easier for us to dogfood ported apps.

2014: Offering Wayland

Fast-forward to 2014. The stable release of 14.04 will be relatively boring (a.k.a. stable :D). Regarding Plasma, it will be based on 4.11 with all the bugfixes we have accumulated until then. Maybe not the most exciting release, but stability and continuity aren’t the worst thing in the world. Also, as 4.11 will get extended support from the upstream Plasma team, this offers quite a nice choice for those that don’t want to upgrade too often.

At the same time, the brave among us will be able to test early versions of Plasma Workspaces 2, which are being constantly updated through Project Neon, a sort of rolling testing releases.

In the first half of 2014, we will start the transition process to the Wayland display server, not for 4.11, mind you, but on top of KDE Frameworks 5 and Plasma Workspaces 2. Project Neon, by that time will get support for Wayland, which likely means that we are going to package a Wayland-based graphicsstack, and maintain that. Not exactly what we’d like to do, but a little more integration work is, in my opinion preferable to rely on a technology which doesn’t provide a stable protocol and is focused solely on another desktop shell. The risk of breakage is not something we want to put our users up with. Us committing to making Wayland available will probably yield a few happy faces in other desktops’ camps as well. So let’s collaborate on that.

Summer 2014 will then (hopefully!) see the first stable version of Plasma Workspaces 2, running natively on a Wayland stack. The time until the 14.10 release will be spent further polishing the living bejesus out of that, so as many of our users as possible will be able to use Plasma Workspaces 2 on top of a fully accelerated graphics stack productively.

22 thoughts on “The next Kubuntu Graphics Stack

  1. Hi, what if the future will prove that Mir is better from a technical perspective? I mean competent people are coding it(and it mainly supports one desktop because the other projects do not seem to get involved).
    Also I want to thank all of the Kubuntu developers packagers for the good work, I am running Kubuntu 12.04 with latest KDe and the experience is great, it would be a shame to have to chose between KDE and Ubuntu in future so please decide between Wayland and Mir when the technical and performance aspects can be compared.2

    1. We can compare them right now, and this is what we base our planning on. If the situation changes dramatically, be sure that we’ll react to these changes. As it looks like right now, users are simply better off with this roadmap as it aims at stability, not disrupting the user experience, while making technological progress.

      Mir targets one desktop as a design decision from day one, not a decision that has been made after upstream projects have expressed their reservations. The barriers for Mir adoption are not purely technical, however. For upstreams, that means: it’s inferior in its development process, in its ability to be interfaces from third party projects, in its licensing and from a development status point of view. These points make the decision fairly straightforward.

      1. Hi, I can’t fione an explanation why wayland MIT license is better then GPL license used the Mir (or why contributing to Qt that is dual licensed is better then contributing to Mir). I nderstand the decision to stick with X for the next LTS but after the next LTS I would like to see a wiki page that compares the status of Mir vs Wayland at that time, I mean if Mir will be on 10 times more computers then Wayland (that maybe will not ship until then. I am developer too, I like coding with Qt and I love KDE apps so as a developer when you work at a project you check if the license is compatible, if is meinteined, then if is buggy or the performance. I applogize, I may wrote to much and maybe I am not making sense(english is not my first language). Again all respect for KDE.Kubuntu developers and contributors, I just hope that good products will not be discarded beause some vocal people on top of KDE have some opinions that are not so much technical but more political (feel free to ignore this comment)

        1. AFAIK this has nothing to do with GPL, and everything to do with the copyright license assignments that are required to work in Mir, essentially giving Canonical the ownership over your work. So, you are not contributing to a community; you are working for Canonical, a for profit corporation, and you are NOT GETTING PAID on top of that. This is unfair. Over that, there are lots of technical issues I’m not aware of.

          1. When you contribute to Qt you also must sign with Digia, and they actualy dual license the code, make it proprietary when the Mir becoming dual licensing or open core is just a FUD for now, anyway the code is GPL3 so the licensing thing seems based on FUD. Anyway as an user I do not expected that I have the right so be agains the developers that do this(since I am not contributing, I tried). One benefit I see from a project run by a company is that people will be asigned to fix bugs where in comunity project if a developer does not have the plesure to fix it will ignore itand work on something intresting(and i understand this 100%) and this penomena gives rise of bugs that could be fixed by a developer in 2 minutes not beeing fixed (are marked as JJ in KDEs case ex

          2. Then you also have to reject any software that’s governed by the Apache Software Foundation, right? Because you also have to grant them copyright for all your work that you contribute.

          3. Non-profit organisations usually have a clause in these agreements, that forbid certain kinds of re-licensing, I know KDE e.V. has for (optional) the Fiduciary License Agreement.

            As Qt’s copyright assignment requirement is different. The setup with the Free Qt Foundation actually makes it almost impossible for Digia to make Qt a purely proprietary project, as Qt will automatically become available under a BSD-style license if that happens. This kind of safety net is, to my knowledge, not there in the CLA Canonical requires, making is significantly different, and to me personally unattractive.

        2. If you want Qt to work with Mir (and you will, if you want KDE to work ontop of Mir), you’ll have to contribute to either Qt or Mir either way. Wayland’s (and Mir’s) license doesn’t really play in here (except in that you may have to link against the library).

          That said, if you contribute to Wayland you may retain Copyright on your code, whereas if you contribute to Mir or Qt you must assign copyright to them. That isn’t necessarily a bad thing, but is something to consider.

          1. This is not correct. The Harmony CLA means you retain your copyright, but also grant copyright to the project you’re contributing to.

        3. KWin has to link to Mir/Wayland, which means it would in turn be converted to the GPL license. While that’s fine for many people, there is a significant subset of people that would prefer not to run GPL. Also, it’s GPL3 only, which means KWin can’t bring in any code that is GPL2 only, or various other licenses it might want. It basically just limits future choices that are currently still open.

          At the end of the day, if Mir was clearly the way forward, people would just accept this and move on. But since there is a reasonable competitor that doesn’t have this issue, it’s perfectly valid to focus on that as a negative for Mir.

  2. @simion
    Yes but in Qt case (copyright license) you have this
    In Ubuntu? Nothing.

    “One benefit I see from a project run by a company is that people will be asigned to fix bugs where in comunity project if a developer does not have the plesure to fix it will ignore itand work on something intresting(and i understand this 100%) and this penomena gives rise of bugs that could be fixed by a developer in 2 minutes not beeing fixed (are marked as JJ in KDEs case ex”

    Well Wayland in KDE is backed by Blue Systems

    Comment made by @simion show how little people know about Blue Systems. It wolud be nice to see some more info about BS as “major KDE supporter” ;)

    1. From wikipedia – “Blue Systems does not have a business model”. No wonder people don’t know much about them. There are trillion businesses like this.

  3. From what I gather from discussions, one of the problems with Mir is that, in an effort to get to their destination the quickest route possible, Mir developers are not going to provide a stable API or protocol, which means breakages are likely along the way. Another reason is that KDE doesn’t want to add special-case code that all the other large (to some measure of large) Linux distros won’t be supporting.

    Sounds like a good goal to me, but I’m not an OSS dev (although I am a dev).

  4. I think wayland is an approach to Mir. As sebas points out, the development model is very important part of the decision. What’s the point of choosing a part of your stack to which you cannot contribute to (and when that part of the stack is designed by people who won’t listen to your requirements).

  5. Thanks for the clarification Sebastian. That sounds like the most reasonable plan.
    Does this decision also mean that LightDM-qt will get Wayland support or are you still waiting until KDE chooses it’s next-gen login manager ?

    1. We haven’t settled with a login manager yet, that means the status quo LightDM remains our prime candidate for now. It’s good enough as long as we don’t require Wayland support from it. We’ll see what happens when the question is on the table again, of course in close collaboration with upstream.

  6. This is exactly what do I feel about systemd, but I am not able to write it as nice and short way as you (I switched Alternatives by Systemd: “Systemd do not provide us any benefits, so instead of jumping onto an unproven and at the time of writing buggy new technology stack…”

  7. Wochenrückblick KW 31…

    Der Wochenrückblick lässt das Geschehen der vergangenen Woche rund um Ubuntu, Linux und Open Source Revue passieren. Top-Nachricht Ubuntu Edge Über Canonicals Crowdfunding-Idee wurde auch in Ikhaya berichtet. Das High-End-Smartphone namens Ubuntu Edge …

Comments are closed.