This weekend a group of KDE hackers met in a small mountain village, Randa, in Switzerland to discuss the future of the KDE Frameworks. I was not present, but started on Saturday an endevour for the future of the KDE Plasma Workspaces. Yesterday evening I arrived in the new world:
This is not just the Desktop Grid effect. The gears window you can see on each of the desktops is a Wayland client, all other windows are X clients. For me this is a rather historic event, not just for KDE but also and especially for Wayland. Up to now there have only been the demo compositor and the QtCompositor as Wayland Compositors. They are more or less just proof of concept. But this is different event: we have here a normal X11 window manager and are able to integrate Wayland clients into the compositing scene just as if it were an X client. This is not a Wayland compositor, it is a X compositor with an implemented Wayland Server component.
This is the proof that there is a sensible migration path from X11 to Wayland. We can use our normal and known X system and manage Wayland clients in it. There is no need to implement the complete stack on top of Wayland first with possible regression. As we can see the Effect Framework does not need any adjustment to support Wayland Clients, which means we can give the user their known KDE Workspace experience. For the user it is irrelevant if a window is an X or Wayland client, it is just a window. For KDE this means that we don’t need and won’t break the desktop. We will switch to Wayland when we are ready, but at the same time we can offer Wayland to interested developers and users who want to experiment with it. For Plasma Active on the other hand we will switch to an X less Wayland-powered KWin as soon as possible.
Of course there is still a long way to go to get to Wayland. This is just rendering, we still need to implement the complete Window Management, transition the compositing away from X, break out X from KWin and lots more. It’s the result of four days where I spent a few hours each day on hacking on that topic. Which shows how simple the Wayland protocol is, although the documentation could be better 😉
Now the next steps will be to clean up the code, document it and push it into a git branch. I hope to see many developers to pick up on it and to start implementing the window manager functionality and extending e.g. Plasma Desktop to support Wayland Clients in the Tasks Applet and many more such things.
I will present the complete KWin Wayland strategy at Berlin Desktop Summit in August.
=-=-=-=-=
Powered by Blogilo
Your dedication is commendable. Thank you!
Simply thanks dude :)!
A small step for kde desktop, a giant leap for the linux desktop.
hehe, I was thinking about which metaphor to use in this blog post and also had this one in my mind 🙂
Awesome! Congratz!
Adenilson
wow!
This is very exciting to see! Keep up the great work!
Awesome.
You just did a huge contribution to the whole linux desktop world. Awesome!
terrific!! that’s great news!
thx very much!
Now that is very, very, very cool! One more reason to use KDE more often 🙂
Best regards…
MacSlow
Interesting approach.
I assume the way that you’ve done this is to run a dummy wayland server from within kwin and have the surfaces output to the existing kwin EGL context? Seems like a fairly simple approach to doing things, then I guess the hard part is actually managing the clients.
I talked to Kristian about this as well, he said that you can do a similar thing in reverse, so when the window manager finally breaks out of the display server area, then you can create an X protocol implementation inside your window manager which the clients connect to, and then you tfp their windows onto wayland surfaces and voila.
I’m doing some other (unrelated) wayland work right now actually, writing a simple compositor which exposes surfaces over DBus (with PolicyKit controls and the like) so that applications can upload shaders to be attached to surfaces and then specify uniform values in those shaders.
I’ve done the first implementation in a few hours, without the DBus bit, but at least attaching random shaders to surfaces and making them do stuff (like gradual animated color inversion). Pretty fun stuff to play with huh?
KWin implements the Wayland server and I have a new KWin::Wayland::Client inheriting from KWin::Toplevel and a small test in the EGL backend whether it is a XPixmap or a Wayland Buffer. The impact on the existing code base is extremly low.
Thanks to the fact that we have an abstract base class, it’s just reimplementing stuff and merge with X Clients as much as possible. Personally I think the most tricky part is input handling (though I have an idea for that).
I would prefer to have a root-less X Server instead of implementing the X protocol in each Window Manager 😉
>Thanks to the fact that we have an abstract base class, it’s just reimplementing stuff and merge with X Clients as much as possible. Personally I think the most tricky part is input handling (though I have an idea for that).
Ah ok, so its a matter of testing if a client handle is an X client or not, only applying client operations supported by the X11 code to X clients and then just passing the texture handle to the paint list.
> I would prefer to have a root-less X Server instead of implementing the X protocol in each Window Manager
Root-less is a nice way to go initially, however I believe this means that you’re getting one single wayland surface for all the X clients. I might have interpreted Kristian wrong, perhaps the better way is to go rootless with some form of input co-ordinate translation from wayland surface co-ordinates to independently laid out X clients on the rootless server (then we just redirect all the pixmaps into each wayland surface … stuff wayyyy ahead in the future)
Dude, you rock!
fantastic stuff, Martin.
although, i have only dabbled in KDE – it is fantastic to see this development in Wayland and KDE.
keep up the great work!
cheerz
Thanks for all the hard work!
Is Wyland supporting X-Atoms or something equivalent?
you can run your own protocol on Wayland, so should be fine, though I did not yet investigate 😉
Amazing! Wayland protocol is extremely simple yet complete indeed, and it is great to know that it could be integrated that easily into kwin. Congrats!