This blog post is a rather important one for me. Not only is it the first blog post which I write in a nearby cafe sitting in the sun and enjoying spring, it is also the first blog post written in a Plasma session running inside kwin_wayland.
This marks an important step in the process of getting Plasma and KWin ready for Wayland as we have reached a state where I can dogfood kwin_wayland on one of my systems. It means that I’m confident enough to write a blog post without having to fear that the session crashes every few seconds (granted I press save a lot nevertheless).
So what do I mean when saying that I’m running a kwin_wayland session? Does it mean that everything is already using Wayland? No, unfortunately not, rather the opposite: all running applications are still using X11, but we use a rootless Xwayland server. The only Wayland application in this setup is Xwayland and KWin itself.
Nevertheless it’s a noteworthy achievement as we now have the architecture pulled upside down. No longer does KWin connect to either an X-server or a Wayland-server which does the rendering to the screen, it does it now all by itself. Over the last week I worked on the DRM (Direct Rendering Manager) backend for kwin_wayland. The DRM backend will become the primary backend for KWin, doing mode-setting, creating buffers for rendering and performing page flips of those buffers on the connected outputs and rendering the mouse cursor on the outputs. In the current state it’s able to get all connected outputs and perform mode setting on them. In addition it can power both compositors: OpenGL and QPainter. The QPainter one is the rather trivial: all we need are two buffers which we map into a QImage to render on. With each rendered frame the buffers are swapped and the last rendering buffer gets presented.
The OpenGL compositor is slightly more difficult. Here we need to introduce another component: GBM (generic buffer management). Gbm allows us to create an EGLDisplay for our DRM device, create an EGLSurface for each of the outputs and get the buffer from the surface to be passed to DRM for presenting. Unfortunately GBM is currently only available on Mesa and given NVIDIA’s presentation at last years XDC it looks like NVIDIA will come up with a different solution. My hope was that this would have settled at the time when we start implementing the solution, but unfortunately that’s not the case yet. So for the foreseeable future it looks like we will first have a Mesa specific backend, then later on can add a new NVIDIA-specific backend and hope that at some future point in time Mesa also supports NVIDIA’s solution (after all it was presented as a generic solution) and we can drop the GBM backend. The situation is none I like, but at the moment we can only ignore the proprietary drivers.
Another noteworthy detail is how KWin opens the DRM device. KWin runs as the normal non-privileged user – thus is not allowed to open the device. Just like libinput integration the DRM backend uses logind to open the device file. Given that we already have support for that in KWin it was a straight forward, elegant and secure way to implement it. I know, that not everybody will agree with this solution. But of course it’s just a DBus interface and anybody can implement it.
There is still quite some work needed before this backend, which got merged into master today, will be fully functional. For example all outputs are set to (0/0) that is render overlapped sections. Here we will in one way or another integrate with kscreen to get sane defaults from the start. I’m so looking forward to being responsible for screen layouts. If I look at all the terrible things one has to do to keep properly updated on XRandR… Now we won’t render with a wrong viewport because different parts of the stack are stuck in different states and no, we won’t freeze just because applications start and call an XRandR call. There are so many things which “just work” and which have been painful on X11. From my first tests on hardware I’m confident that we will finally have working multi-screen handling which is adequate for 2015.
Of course this is a wonderful time to start working on KWin. There are lots of small tasks to work on. I am constantly adding new tasks to our todo list. And if you ask, I can always provide some more small tasks.
15 Replies to “Turning the world upside down”
Sounds awesome! Thank you for your great work!
Does this mean KWin_Wayland is its own standalone display server with no middle man at this point (even if it can only manage a single client at this point)?
Anyways, I’m excited for a better Plasma experience that Wayland can bring (particularly more multi-touch gestures besides two finger scrolling)!
As always, thanks for the updates!
Excellent, glad to hear all your hard work is paying off.
Does this mean the next release will have Wayland as a supported platform (even if everything else is running on Xwayland)?
Yes, I hope that we can take it out of the experimental state in 5.4
Congratulations Martin, good job as usual.
Now, as far as I am concerned, systemd is just fine (a complex solution to a complex problem) but… exactly how much of Kwin is depending on dbus now?
Kwin has been dbus dependent since 4.0. So honestly I don’t get your question.
Ah well… there you go then 🙂
Very nice, thanks for sharing your progress.
Stop me if I misunderstood something but I wonder, since KWin can now run even on KMS does it mean it could be used as a “system compositor” ? Eg : It could be nice if SDDM ran on KWin to ensure seamless transitions between users and desktops.
Probably not as we want KWin to run as same user as the desktop shell and not as sddm user. Though Sddm could start it’s own KWin instance
I don’t think anyone should be hyped for the Nvidia solution nor expect it to become a part of Mesa, see http://thread.gmane.org/gmane.comp.freedesktop.wayland.devel/20699 (the correct solution would be for Nvidia to go down the established road and contribute there, if they’re not happy with some specific part)
I hope my blog post isn’t read the way that I think that Nvidia’s solution should be hyped. Rather the opposite. I’m very unhappy with the situation and I want one solution to drive both mesa and Nvidia.
Oh, well it did sound a bit like you preferred any solution from Nvidia, since you want Mesa to adopt it and than go with that.
As far as I’m concerned I really no longer care for Nvidia (yeah, I know, not an option for you). They just don’t want to play nice, so I don’t buy their GPUs. And since the FLOSS Radeon and Intel drivers work very well – games included – I really don’t see a reason to go back until Nvidia’s desktop department learns something from their embedded guys. /rant
Anyway, thanks for the clarification and your work!
windows has a nifty feature that when the compositor crashes, the applications survive the crash and the compositor just restarts itself. Can you pull that off in Wayland.
From the compositor side: sure. The question is more what the applications do: if they quit when the connection goes away there is nothing the compositor can do. But that it’s possible to not quit can be seen in the KWayland::Client library which handles restarting compositors just fine.
Comments are closed.