A few weeks ago I blogged about the new KWayland module in our workspace modules. Back then I also mentioned the server component of KWayland and that it’s not part of the 5.1 release. Yesterday I finally committed a change to install the library and the header so that starting with Plasma 5.2 the server component is also available. This is a good point in time to explain what the server library is and what can be done with it.
Like the client library the server library is a very low-level Qt wrapper for the Wayland server library. So the main task is to be a Facade to wrap the C library in a for us easier to use Qt style API. E.g. it’s emitting signals when the C callbacks are invoked and hides all the required C casts of void pointers. Nevertheless we still have access to all the wraped Wayland members, so it allows to easily combine KWayland::Server with wayland server code.
KWayland::Server is not a wayland compositor. It is deliberately designed to be head-less, which makes it a wonderful solution for using as a backend for automated tests. E.g. for kscreen it is used to simulate changes in the screen setup which is a huge improvement over the state we have on X11 where there is basically no chance at all to test screen changes.
Although the library is head-less the repository contains also some test applications including a wayland compositor which can render:
 |
| Aus KWayland |
The actual compositor is a good old QWidget connecting to the X-Server. It starts a Wayland server and can render the buffers provided by connected clients, in this case KInfoCenter showing the Wayland module (which uses KWayland::Client). KInfoCenter is run using the Wayland QPA, so it’s a native application and doesn’t use X11 at all.
Overall this test compositor is just about 200 lines of code and supports not only rendering, but also input as can be seen in this screenshot of kate:
 |
| Aus KWayland |
Unfortunately the KWayland::Server module doesn’t support the test applications provided by Weston yet. The reason for this is that those applications expect the xdg-shell protocol to be present. But this protocol is not yet supported by KWayland::Server and won’t be supported any time soon, due to the unstable nature of that protocol. So for the time being one can only test with QtWayland and the small set of test applications provided by the KWayland repository (those can of course be run against Weston).
Of course there is still a lot of work to be done in the server module – the code is full of TODOs. Helping hands are of course welcome and Google Code-In students can expect a few tasks around the KWayland::Server module 😉
Now that the server module gets installed we can start using it in applications. I have a plan where to integrate it for the 5.2 release (teaser: it won’t be KWin) and depending on how much time I find for it, kwin_wayland might also get to the state that it starts a server. But Christmas and feature freeze are approaching, and there is still lots of other things to work on.
If you like the work we are doing, consider donating to KDE:
The donations are used to e.g. sponsor developer sprints where we can discuss the implementation of Wayland in the Plasma workspaces.
Still no Bitcoin donation possible.
No open source money for open source software?
I’m sorry but I’m the wrong one to ask about Bitcoin donations, you would need to contact the e.V. Personally I assume that there are either legal hurdles or it’s just not worth the effort.
Is this something like nested xservers?
it can be used to implement something like nested xservers. It’s a library and by that relatively flexible.
This sounds like KWayland::Server is comparable with QtCompositor.
Both are head-less APIs which wrap libwayland-server into a Qt-API.
If I still don’t get it … forgive me 😉
If I actually got it … whats the reason not to use QtCompositor?
Maybe the level of abstraction? (I think it’s not indented to access the actual wayland “objects” from QtCompositor)
QtCompositor is unreleased software and thus cannot be used as a base for our software. This makes it unfortunately a no-go anyway, but it’s not the reason.
QtCompositor is as the name says an API to design a compositor using QtQuick. This is in fact a feature we don’t need. I also disagree on the point that QtCompositor is head-less. To me it isn’t as it provides rendering code. A QtQuick based compositor is no solution for KWin as we already have our compositor and want to share it with the one used on X11. Changing the architecture to use QtCompositor would be too much work.
Furthermore KWin will need to integrate with the Wayland protocol directly. We will have plasma-specific protocols requiring us to go down to wayland protocol level. As it’s unlikely that QtCompositor would accept patches for that we would need our own solution anyway. Thus we would have to interact with multiple different ways to interact with Wayland.
Also given the experience of the Qt5 port I would introduce a facade between KWin and QtCompositor anyway to be able to exchange it in case e.g. Qt6 drops it or whatever. If we implement a facade anyway we can also implement directly a facade for Wayland – and that’s what KWayland::Server is.
got it @ not released & uncertain future!
Although one could argue that if a big project as kwin picks it up the two project should be able to align and both should benefit … and even if goals divert you could as a (bad / last resort) fall-back fork the code.
Also I do get the whole deep integration part … this I can easily see being a bigger problem (as in: you would need to solve that before you can actually benefit from QtComp)
Good reasons, makes sense.
Another thing though:
You’re wrong with the whole QtQuick part!
You can even build QtCompositor without QtQuick if you like. In any case you can write your complete compositing how ever you like (e.g. native OpenGL) … see:
examples/wayland/qwindow-compositor/
It doesn’t ship any rendering on it’s own … IMHO it’s headless .. .what head you put on it (qml, native opengl, other khronos rendering,…) is up to you.