Four years later

At beginning of June 2011 I made my first blog post about KWin support Wayland clients featuring a screenshot of Desktop Grid effect with a Wayland window shown on each desktop.


Now it’s almost four years later and I show once again such a screenshot:

Desktop Grid effect in a Plasma on Wayland session
Desktop Grid effect in a Plasma on Wayland session

A few things have changed, for example the screenshot shows a KWin running on DRM. And there’s one huge difference: the KWin instance is using Wayland internally and no longer X11 (it still uses it for X11 applications, or course). Also KWin is able to properly integrate the Wayland windows. They are not rendered a top of the scene but take up normal spots like all other windows, too. Otherwise they are also more like “normal” windows. The plasmashell in this screenshot is also a Wayland client including all the panels and windows it creates (not visible as desktop grid effect hides panels).

A good question to ask is how much of the initial code written in 2011 ended in todays KWin and the honest answer is none. The branch got never merged and pretty quickly bitrotted. I got the rendering done pretty quickly, but at that time Wayland hadn’t had a stable release yet, so we simply couldn’t merge the code into master as that would have been rather inconvenient for development. With two moving targets (Wayland and KWin) the code diverged too quickly, broke too often and made development difficult. Thus when I heard a stable release of Wayland was planned it didn’t make much sense to continue the work on the branch.

But there was of course one thing which the branch provided: experience. The branch showed that our compositor is up to the task of integrating non-X11 windows, but the rest of KWin wasn’t. Which triggered a refactoring to make KWin more useable with multiple platforms. There were side-effects from that development which went already in some releases: e.g. the reworked scripting helped to identify the interface of a managed Client. Very recently this got split out into a new abstract base class which is now inherited by the good old X11 Client and the new Wayland ShellClient. A different area is screen edge handling which got reworked to not only allow multiple backends but also to have more fine grained per screen edges.

The work to get Wayland integrated into KWin took much longer than expected, part of it was the problem described above of the missing stable Wayland releases. Of course there was also a Qt5 port which I didn’t expect. The Qt5 port required a port to xcb – again something I didn’t expect. But most of all I underestimated the problem scope of how much work would be needed to get the window manager ported to Wayland. Still it will be quite some time till all features which are provided by KWin will be available for Wayland. Too much code is too X11 specific to be directly reusable.

And to get a complete session up and running there is much more to be ported than just KWin. We have Plasma which needs to access window management information provided by KWin (a taskbar should be able to show tasks after all). Some parts need to be moved into KWin for better security: screen locker and global shortcut handling (almost finished) are obvious candidates. We have functionality provided in our libraries which need adjustments: examples are KWindowSystem and KIdleTime. Our power management code need to learn how to talk with KWin to turn the screen off. KScreen needs to learn to interact with KWin to configure screens. And much, much more.

Also many of our applications need to be adjusted to work properly on Wayland. Obviously if one uses low-level X11 calls those won’t work any more. But also when you use higher level abstractions it might be that your feature doesn’t work any more, there are so many things which are X11 specific and you might not even know off. I plan to host a session on “Applications on Wayland” on this years Akademy. Make sure to go there. I’ll show all the “don’t” (and most are don’t on X11, too 😉 ) and show how one can easily setup a Wayland session to test the application.

Now I know that this blog post sounds a little bit like one shouldn’t expect Wayland on Plasma anytime soon. That’s not the case. I’m quite optimistic that I will shift my systems to Wayland as the primary work system before Akademy to properly dog food. And I’m sure that many Plasma developers will soon follow. After all I’m just editing this blog post in a full Plasma on Wayland session (though my Firefox is using XWayland).

And of course there are many, many tasks to work on. Most are really easy and easy to get into. Every contribution matters and helps us to embrace Wayland faster. Setting up a KWin development environment to test the Wayland progress is easy. All you need is to build kwayland and kwin through kdesrc-build (all other dependencies can be provided by your distribution). Once it’s installed just run:

kwin_wayland --windowed --xwayland

and a nice nested Wayland server will be started in your X session.

And if you want to get all down to running KWin directly on DRM like the screenshot above:

kwin_wayland --drm --libinput --xwayland

In all cases you can specify applications to be launched once KWin has fully started. Those can be either X11 or Wayland applications, e.g.:

kwin_wayland --drm --libinput --xwayland "konsole --platform wayland"

Will start a konsole as a Wayland client once can has started.

A recent addition as of today is that you don’t have to specify the commands like windowed or drm any more. KWin will automatically pick the correct backend depending on the environment variables which are exported. But be careful: if you start a kwin_wayland on an X session without DISPLAY exported, it will start the drm backend and that might break your X session!

19 Replies to “Four years later”

  1. Finally!
    Thank you for your great work on this, Martin.

    If you don’t mind me asking, how is the performance?

    1. If you don’t mind me asking, how is the performance?

      That’s nothing I care about at the moment.

      1. IOW, it’s not so bad that you can’t write a blog post while using it, but don’t expect it to be great (or even decent), either? 😉

  2. That’s a lot of very impressive work, Martin – thanks a lot 🙂 . I sure hope that Debian won’t take too long to get KDE 5 packages, so that I can finally try some of that stuff…

    Now, considering that you mention the DRM backend, there’s one question coming to my mind immediately: Do you have plans to take technical advantage of the fact that you have lots of control over the rendering here? In particular, I am thinking of some optimizations that gamers will love. If you have a full-screen window, you could swap to that window’s buffer and provide 0-copy rendering. (Currently, on KDE4+X11, I disable compositing when playing games as the additional latency and performance drop is noticeable.) And to take that even further, one could use the multiple planes that modern Intel IGPs provide, and even render the topmost few windows (where changes will typically happen), and perform color conversion, without any copies. Weston does all this. But I am kind of worried that the more abstract nature of KWin may make this harder than it is for Weston, because it may break some of the abstractions you established.

  3. As usual, very interesting update. Thank you and all the Plasma team for your work, I am really looking forward to try it.

    One question : ” We have functionality provided in our libraries which need adjustments: examples are KWindowSystem and KIdleTime. Our power management code need to learn how to talk with KWin to turn the screen off. KScreen needs to learn to interact with KWin to configure screens. And much, much more.”
    Is it specifically KWin, or is there a common interface for all “wayland-servers” (or whatever is the correct term) ? I mean, currently, even if nobody is doing it anymore as KWin is obviously the best X11 window manager, you can use Compiz, Mutter or OpenBox on top of Plasma. Will this still be possible in the wayland world or will Plasma be tied to KWin ?

    1. The interfaces we design (I’ll blog about one soon) will hopefully be of use for other projects as well and those which I think can be of use for everybody (idle time) I will also try to contribute to Wayland directly.

      Plasma will be bound to the interfaces – they are even called PlasmaWindowManagement and do not have KWin in their name. Thus Plasma will work on any Wayland compositor providing such interfaces. If they are missing features might get broken. That similar to the state on X11. Yes, you could use e.g. Compiz, but some features and visual parts will break as other window managers do not provide the interfaces Plasma uses and KWin provides.

    1. Nothing constructive to say, but as one of many KDE users, thanks for rocking our little world

  4. Wayland windows only know relative coordinates, right? Will things like a window opened in a position where the window decorations (maximise/minimise/close button) be off screen a thing of the past? His regularly annoys me on both Linux/KDE and MS Windows.


      1. Hmm, not in my case. To be precise, I experience this behaviour with two monitors next to each other, where the window is aligned to the top of the higher screen, but it is horizontally placed on the screen with the smaller height, making only the lower part of the window visible. This happens with pokerth and LibreOffice dialogs.

    1. yes we will have server side decorations with Qt 5 windows. Luckily there is an env variable (QT_WAYLAND_DISABLE_WINDOWDECORATION=1) to disable them. I have so far not yet implemented it as I somehow need to recognize the Wayland and X11 windows during development 😉

  5. OT:
    Is there a reason for the often unreachable state (“Database Error”) of you blog, especially during (european) night time? Are you hosting this blog from home?

    It’s kinda annoying …

    1. No, I’m not hosting from home. The problem seems to be related to heavy load caused while I’m a sleep. I just don’t have the time to investigate.

Comments are closed.