Plasma’s Road to Wayland

Road to WaylandWith the Plasma 5.0 release out the door, we can lift our heads a bit and look forward, instead of just looking at what’s directly ahead of us, and make that work by fixing bug after bug. One of the important topics which we have (kind of) excluded from Plasma’s recent 5.0 release is support for Wayland. The reason is that much of the work that has gone into renovating our graphics stack was also needed in preparation for Wayland support in Plasma. In order to support Wayland systems properly, we needed to lift the software stack to Qt5, make X11 dependencies in our underlying libraries, Frameworks 5 optional. This part is pretty much done. We now need to ready support for non-X11 systems in our workspace components, the window manager and compositor, and the workspace shell.

Let’s dig a bit deeper and look at at aspects underlying to and resulting from this transition.

Why Wayland?

The short answer to this question, from a Plasma perspective, is:

  • Xorg lacks modern interfaces and protocols, instead it carries a lot of ballast from the past. This makes it complex and hard to work with.
  • Wayland offers much better graphics support than Xorg, especially in terms of rendering correctness. X11′s asynchronous rendering makes it impossible to be sure about correctness and timeliness of graphics that ends up on screen. Instead, Wayland provides the guarantee that every frame is perfect
  • Security considerations. It is almost impossible to shield applications properly from each other. X11 allows applications to wiretap each other’s input and output. This makes it a security nightmare.

I could go deeply into the history of Xorg, and add lots of technicalities to that story, but instead of giving you a huge swath of text, hop over to Youtube and watch Daniel Stone’s presentation “The Real Story Behind Wayland and X” from last year’s LinuxConf.au, which gives you all the information you need, in a much more entertaining way than I could present it. H-Online also has an interesting background story “Wayland — Beyond X”.

While Xorg is a huge beast that does everything, like input, printing, graphics (in many different flavours), Wayland is limited by design to the use-cases we currently need X for, without the ballast.
With all that in mind, we need to respect our elders and acknowledge Xorg for its important role in the history of graphical Linux, but we also need to look beyond it.

What is Wayland support?

KDE Frameworks 5 apps under Weston

KDE Frameworks 5 apps under Weston

Without communicating our goal, we might think¬†of entirely different things when talking about Wayland support. Will Wayland retire X? I don’t think it will in the near future, the point where we can stop caring for X11-based setups is likely still a number of years away, and I would not be surprised if X11 was still a pretty common thing to find in enterprise setups ten years down the road from now. Can we stop caring about X11? Surely not, but what does this mean for Wayland? The answer to this question is that support for Wayland will be added, and that X11 will not be required anymore to run a Plasma desktop, but that it is possible to run Plasma (and apps) under both, X11 and Wayland systems. This, I believe, is the migration process that serves our users best, as the question “When can I run Plasma on Wayland?” can then be answered on an individual basis, and nobody is going to be thrown into the deep (at least not by us, your distro might still decide to not offer support for X11 anymore — that is not in our hands). To me, while a quick migration to Wayland (once ready) is something desirable, realistically, people will be running Plasma on X11 for years to come. Wayland can be offered as an alternative at first, and then promote to primary platform once the whole stack matures further.

Where at we now?

With the release of KDE Frameworks 5, most of the issues in our underlying libraries have been ironed out, that means X11-dependent codepaths have become optional. Today, it’s possible to run most applications built on top of Frameworks 5 under a Wayland compositor, independent from X11. This means that applications can run under both, X11 and Wayland with the same binary. This is already really cool, as without applications, having a workspace (which in a way is the glue between applications would be a pointless endeavour). This chicken-egg situation plays both ways, though: Without a workspace environment, just having apps run under Wayland is not all that useful. This video shows some of our apps under the Weston compositor. (This is not a pure Wayland session “on bare metal”, but one running in an X11 window in my Plasma 5 session for the purpose of the screen-recoding.)

For a full-blown workspace, the porting situation is a bit different, as the workspace interacts much more intimately with the underlying display server than applications do at this point. These interactions are well-hidden behind the Qt platform abstraction. The workspace provides the host for rendering graphics onto the screen (the compositor) and the machinery to start and switch between applications.

We are currently missing a number of important pieces of the full puzzle: Interfaces between the workspace shell, the compositor (KWin) and the display server are not yet well-defined or implemented, some pioneering work is ahead of us. There is also a number of workspace components that need bigger adjustments, global shortcut handling being a good example. Most importantly, KWin needs to take over the role of Wayland compositor. While some support for Wayland has already been added to KWin, the work is not yet complete. Besides KWin, we also need to add support for Wayland to various bits of our workspace. Information about attached screens and their layout has to be made accessible. Global keyboard shortcuts only support X11 right now. The screen locking mechanism needs to be implemented. Information about Windows for the task-manager has to be shared. Dialog positioning and rendering needs to be ported. There are also a few assumptions in startkde and klauncher that currently prevent them from being able to start a session under Wayland, and more bits and pieces which need additional work to offer a full workspace experience under Wayland.

Porting Strategy

The idea is to be able to run the same binaries under both, X11 and Wayland. This means that we (need to decide at runtime how to interact with the windowing system. The following strategy is useful (in descending order of preference):

  • Use abstract Qt and Frameworks (KF5) APIs
  • Use XCB when there are no suitable Qt and KF5 APIs
  • Decide at runtime whether to call X11-specific functions

In case we have to resort to functions specific to a display server, X11 should be optional both at build-time and at run-time:

  • The build of X11-dependent code optional. This can be done through plugins, which are optionally included by the build-system or (less desirably) by #ifdef’ing blocks of code.
  • Even with X11 support built into the binary, calls into X11-specific libraries should be guarded at runtime (QX11Info::isPlatformX11() can be used to check at runtime).

Get your Hands Dirty!

Computer graphics are an exciting thing, and many of us are longing for the day they can remove X11 from their systems. This day will eventually come, but it won’t come by itself. It’s a very exciting time to get involved, and make the migration happen. As you can see, we have a multitude of tasks that need work. An excellent first step is to build the thing on your system and try running, fix issues, and send us patches. Get in touch with us on Freenode’s #plasma IRC channel, or via our mailing list plasma-devel(at)kde.org.

7 Responses to “Plasma’s Road to Wayland”

  1. RJVB says:

    Just wondering, would it be possible to do things in a way that neither X nor Wayland is required, in view of running under OS X or MSWin?

    • mgraesslin says:

      For applications that’s not a problem – it just works like Wayland just works. For the workspaces: well there’s a reason why we use X11 or Wayland directly, we don’t do that because we think using X11 is so much fun ;-) In the same way one would need to get the required calls for Windows in to be able to start a desktop shell. For a Linux focused team it’s unlikely to happen. For OS X it’s AFAIK impossible to exchange the desktop shell.

      • Rsh says:

        Just out of curiosity, will wayland and X11 backends have a clear single-point implementation under a sensible abstraction layer? This way … Windows folks could implement their own … if Windows has the required bits.

        • Diego. says:

          For the record, Plasma Shell already runs under Windows. Main problem is that some integration bits are really difficult or even impossible to do. Of course, there’s not a high interest in doing that, as KDE on Windows project still hasn’t big traction.
          http://youtu.be/L3CSwR3CrsQ

        • mgraesslin says:

          For plasmashell it’s possible – the needed X11 bits are not so many and mostly already abstracted over KWindowSystem. For something like KWin it’s kind of impossible. Windowing systems are too different to make a useful abstraction. Windows especially is a too different beast – needs Direct3D for a compositor, etc. etc.

      • RJVB says:

        I was afraid you’d say that ;)

        Well, if Wayland could become an app in its own right as XQuartz is on OS X, at least one could put it in fullscreen rootless mode and override the OS X desktop rather than replace it ;)

  2. Duncan says:

    > H-Online also has…

    (Excited.) Wait a minute, “has” is present tense, but I remember being dismayed when they shutdown. Does this mean they’re back?

    (After checking the link, dissappointed…) No… Old article from 2012. Too bad. =:^(

    Watching and waiting for both plasma5, and somewhat further out, plasma5 on wayland, here. I tried plasma5 on X a week or so ago, but at least here on gentoo, qt5 isn’t even in the tree yet, and in the qt overlay they’re still working on integrating qtchooser support to help qt4 and qt5 play well together, so it was experimental on experimental and that didn’t work so well. Besides, kwin5 didn’t like my radeon turks with native kernel drivers graphics, and ended up in a segfault and respawn loop, so after two days of work just getting it installed, all I saw of plasma5 was a couple borderless (crashed kwin) error dialogs. =:^( I’ll probably wait at least until the qtchooser integrated qt-4.8.6 is in the main tree, hopefully along with qt5, so at least I won’t have that layer of experimental to deal with, before trying again. That’ll give frameworks5 and plasma5 a bit longer to mature as well, and hopefully I’ll get a bit more than a respawning kwin and a couple borderless error dialogs next time. =:^)

    Still looking forward to it, and to running it on wayland a bit further out, tho. =:^)