Posted on by Martin Flöser

Wayland accelerated at CERN

Last week I attended the KDE sprint at CERN to discuss the next steps in Wayland development with my fellow Plasma developers and our awesome crew of the visual design group.

With the feature freeze just behind us it’s a good time to look at where we stand and what still needs to be done. For me it was a quite exciting sprint as it meant one week of working on Wayland. My notebook is my Wayland test system, so also during the sprint I worked on Wayland. The only exceptions to be on X11 was to investigate problems in Wayland which is still easier from a nested setup on X11 (mostly due to the fact that my notebook has only Qt 5.5 which doesn’t support pressing Ctrl+C in a Konsole). But I was not the only one testing Wayland: my fellow developers did as well and reported interesting bugs I never hit (if you hit a Q_UNREACHABLE something is seriously wrong) due to running a Qt release build. At some point we had the majority of attending Plasma devs running a Plasma Wayland session.

While using a full session one realizes what’s missing in the workflow. As a result we have KRunner working on Wayland now (including a nice improvement for X11) and Yakuake working (with the Ctrl+C exception mentioned above). Some devs also need Ctrl+Alt+Backspace to kill the windowing system in their workflow. So that’s now also implemented – don’t be afraid: it follows the X-server settings and is by default disabled in the keyboard layout.

One problem we noticed is that our possibilities to debug a running Wayland session is rather limited. Especially we are lacking tools like xprop and xwininfo. A window is misplaced, why is that? Currently answering that is still rather tricky. So for the next event cycle I want to improve here to make it very easy for debugging a running KWin instance without needing external tools like xprop and xwininfo. As a start I hacked together a small debug console which can be invoked through DBus:
KWin Debug Console

Of course we did not just hack, but also plan the future. Most importantly we had a session together with the visual design group to explain what new possibilities are there on Wayland. The VDG will hopefully soon come up with some new ideas on how to improve the workflows 🙂 Also we had a good discussion about dynamic window decorations – Ken is going to report about that, so I won’t steal the show on that.

KWin was not just a topic for the Plasma crowd. Also WikiToLearn has a very interesting setup with KWin in the cloud. This is really exiting and looking promising. It might be that some of my crazy ideas might finally get implemented as I now see use cases for KWin streaming textures into a HTML5 web socket.

And of course we saw KWin in the CMS control room 🙂
CMS Control Room

Thanks to CERN for hosting us and making it possible to visit the LHC. Thanks to KDE e.V. for sponsoring the sprint. WikiToLearn and especially Riccardo for organizing the sprint.

If you want to support our sprints in future consider becoming a supportive member.

13 Replies to “Wayland accelerated at CERN”

  1. So KWin on Wayland not only requires systemD but also a large particle accelerator to run. This simply isn’t the Unix way, it’s fascism. This is the last straw, I’m switching to BSD.

    1. apparently … as i do have seen kwin in use at ESRF, DLS and BESSY too. there must be some connection between these occurances 😀

  2. know now in “It might be that some of my crazy ideas might finally get implemented as I *know* see use cases for KWin streaming textures into a HTML5 web socket.”?

  3. Pingback: DWD Structured @ CERN – Ken Vermette

  4. Could “streaming to HTML5” also be (ab)used for some kind of “remote desktop” feature? 🙂

    1. yep, that was actually the main idea I had years ago when I first had the idea. Moving to cloud is more the side effect.

  6. I know that this article is not the best place to post this question/commend, but comments under another article regarding gaming on Wayland are closed.

    You have said something like that:
    With windowing system:
    “Game renders through OpenGL/EGL
    Compositor gets notified through wl_surface damage
    Compositor directly presents the wl_buffer through KMS as it knows there is nothing else to see”
    and:
    without windowing system:
    “This would allow the game to open the device files for rendering and for input just like a Wayland compositor does. Rendering could be done through EGL on top of DRM/GBM just like a Wayland compositor.”

    I don’t understand what happens when windowing system is in place (KWin is a compostior) and app in windowed mode is using OpenGL/EGL.
    Does that application, in windowed mode, use EGL on top of DRM/GBM or is communicating with something else? If latter is true, with what this app is communicating via EGL?
    On top of what is placed EGL for app running as Wayland client in windowed mode, when KWin is compositor?

  7. Is there a risk of opening a “quantum fissure” if I try to run a Wayland session then 😎

    Nicely done to the whole KDE team…
    Martin I am especially the impressive performance of Kwin on Plasma 5.6.1 – even if it’s just in an old fashioned X11 session 🙂 Blows chunks off the other DE Window Managers…

  8. Martin can you please tell me something more about becoming a KDE e.V. supporting member? I always donated when I saw someone organising a sprint, but I never heard about it.

Comments are closed.