Today we released Plasma 5.1 which features a new library called KWayland. KWayland originates from KWin and got split out to allow code-reuse especially in KDE components which use LGPL instead of GPL.
Client
So what is KWayland? KWin/Wayland supports compositing to a Wayland surface instead of an X11 Window for quite some time already. For this KWin has to “talk” with a Wayland compositor. It needs to create the surface, map the rendering buffer, get input events, update the cursor image, etc. etc. In fact it’s just a normal Wayland client. The Wayland libraries have a nice callback mechanism, but it’s not very handy for Qt developers who would for example prefer getting a signal emitted instead of a static callback being invoked. So the code we had in KWin was kind of wrapping the low-level C API into a little bit higher-leverl Qt-style API.
Now after 5.0 got released we had more time to work on Wayland with the result that more developers started to look into the code and also had the need for this Qt-style API. An example is kscreen which needs a Wayland backend. In order to not duplicate work or have similar API in multiple projects, we decided to split out the code from KWin and turn it into an own library. And the result is KWayland.
So far KWayland in 5.1 provides a Qt-only (in frameworks speak tier 1) client library which wraps a limited subset of the Wayland client API (basically whatever KWin needs). It is still low-level enough that one can just combine it with the low-level C library, each instance of a class can be casted into the respective Wayland type. A lot of work went into the client library to clean it up for the first release as initially the code was never intended to be used as a library. In 5.1 it’s already used in two components: KWin and KInfoCenter. KInfoCenter has a Wayland module since 5.0 and the low-level code could completely be replaced by the library and in addition more information can be shown.
Server
But there is more in KWayland. There is also a server library which is not yet released. This server library will be used by KWin to implement the Wayland compositor. And it’s already used – not yet by KWin (though I have POC code), but by KWayland itself. It’s the backend for the auto tests. Each test case starts a dedicated Wayland server created with the server library. This is really convenient and a huge step forward compared to the situation we have on X11. It allows us to easily test both client and server API at the same time.
How does it relate to QtWayland?
QtWayland solves a different problem than KWayland. QtWayland main purpose is to be a QPA plugin. KWayland is intended for cases when the abstraction is not enough and one has to low-level interact with Wayland. Just like we have applications using X11 directly although there’s a QPA for it.
Having just played with the Server API in KWayland, that is pretty awesome, especially for tests.
I can set up a server exactly as I’d like (outputs, for example, with different modes), and test for that, all from the same file.
Very cool.
Thanks, and that’s exactly what I had in mind when writing that code 😉
What’s the relationship to QtCompositor? (the server part of QtWayland).
It solves a similar purpose as what you describe in “Server”
also none. It solves different problems. QtCompositor is as the name says a compositor, while the Server library is head-less and doesn’t support any output at all.
So how does kwin become/integrate a/into compositor then?
Are you planning to write a compositor “from scratch” or do you plan to integrate into another compositor (e.g. write kwin as a shell for weston)?
If it’s a shell for weston … why not use QtCompositor instead and make kwin a compositor itself? … sound like less effort then integrating into a completely different technolgy (weston/efl)
KWin is already a Compositor. We just reuse the Compositor we have for X11.
Would the client library be something like “QtWaylandExtras”?
Or does it even go beyond that?
It kind of goes beyond that as it doesn’t need the QtWayland QPA (which is important for KWin as we still require the xcb QPA) and can be used with a QCoreApplication. Once QtWayland is released and we depend on that Qt version I’m interested in making it possible to integrate with the QPA, though at least for the primary use-case (KWin) it’s not needed.
Thanks for all your hard and awesome work, Martin !
You didn’t allow comments in your other recent Wayland posting 😉 so I’m asking here, it’s still KWayland-related.
> This means we need to handle input (which libinput does) and
> need to interact with DRM directly. DRM support is still
> missing. This could be an interesting GSoC project next year 😉
Are you sure it is a good idea (and necessary) to re-implement all that nifty DRM stuff Weston does? Like, automatically using hardware planes to do less compositing in software, a special logic to do just a single flip in case of a full-screen top-level window (or actually not just top-level, if hardware planes come in), etc.? That sounds like a huge waste of effort to me.
Wouldn’t it be possible to, for example, become an xdg-shell that can re-use all the magic Weston does?
honestly I would prefer to not needing to go all DRM. But I’m getting less and less convinced that we can just run on top of Weston. That starts with problems like not being able to tell Weston to not process input events, goes over no way to get kscreen interact with it and so on. We would have to put lots of work into Weston first.