Posted on

Why don’t you just…

Relatively regularly I’m asked why I don’t “just” integrate QtCompositor or libweston and call it a day. Well it should be obvious, if it were as simple as “just” we would do that 😉 So instead of replying again and again I thought to give a full blog post explaining the options and why they don’t really suit our needs.

How KWin’s compositor works

Let’s start with a look at the Compositors in KWin:

  • No Compositing (X11 only)
  • XRender (X11 only)
  • QPainter (Wayland only)
  • OpenGL (ES) (X11 and Wayland)

The task of the compositors is to render the windows into a global scene. The information about the windows is taken from the window manager (e.g. the stacking order defines which window is rendered on top) and get transformed by the effect system.

The compositors use platform specific API to get the content of the window and to render it to the screen. E.g. OpenGL can use GLX and use texture from pixmap to map the content of an X11 window to an OpenGL texture and use an XWindow to create the OpenGL context on. The actual compositor which renders doesn’t care whether it’s an X11 Window or a Wayland window or whatever, all it cares about it’s a texture (OpenGL), a pixmap (XRender) or a QImage (QPainter). The platform specific API is abstracted allowing to make the actual compositors completely windowing system agnostic. Designed as a class diagram it looks (simplified) like this:

Now with that much abstraction one could think that there a huge differences between the code and that there is not much sharing going on. But the opposite is the case. The majority of the code is shared. To give an overview I provide the line count of all the files relevant to the OpenGL compositor.

  • Shared code: 3733 (cloc scene_opengl.* abstract_egl_backend.* scene.*)
  • Platforms specific: 1424 (cloc egl* glxbackend.*)

From the platform specific code the glxbackend is about 50 %. The sharing between the egl backends is larger, for the new X11 mode for kwin_wayland the difference is just 20 lines. For QPainter the differences are also rather small – in fact the differences are so small that all is in one source file making something like 200 lines of code for the three backends. Last week I worked on integrating a framebuffer backend into QPainter – although I prior had no idea about it, it was integrated into KWin in less than two hours fully functional with no change to the SceneQPainter at all except writing 50 lines of the backend code.

Now the backends are only part of the whole story. By using our own existing compositor we ensure a similar feature set between X11 and Wayland and can reuse all our effects directly without any adjustments. According to CLOC we have 22000 lines of effect code.

What about QtCompositor

QtCompositor seems to be the natural choice for bringing Wayland support to KWin. After all it’s part of Qt which is what we use in KWin. Except it doesn’t. For a starter it’s not yet a released component which makes it difficult to use for us to develop against, for our packagers to distribute and for our users to test. “But Martin”, you say, “you could develop on it and get it into a release state!”

Yes I could, but would it help KWin? What is the strength of QtCompositor? Providing a QtQuick API to write a Wayland compositor. But KWin doesn’t use QtQuick in the compositor. “But Martin”, you say, “QtQuick is the new cool thing, everybody ports to it, so should you!”. Yes, of course, but it means:

  • Throwing away all our effects
  • Writing new integration code between QtCompositor and the window manager
  • having no code sharing between the Wayland and the X11 compositor
  • No longer being able to provide non-OpenGL compositors as QtQuick requires OpenGL

If I look at this I rather doubt that this would be a “just integrate it”. That looks like a lot of work and duplication to have the same basic window manager for X11 and Wayland. Code sharing would be kind of impossible as the technologies involved are too different.

“But Martin”, you say, “you could at least use QtCompositor for wrapping the Wayland API and use it to map a Wayland buffer to OpenGL!” Yes, that is true and I did consider it and even planned to do so. In the end I decided against it for multiple reasons. First of all this still shows the problem of the unreleased component (yes, I could work on it), but then I wanted to integrate Wayland in KWin with a Facade. Using a facade is something I consider here as rather important. After all we want to use Wayland for quite some time and not run into the situation that we need to port away from a library in a few years. Using a facade makes such a situation much easier. Now if we write a facade anyway what is the benefit of being a facade to QtWayland compared to being a facade to Wayland directly? It just adds another layer of abstraction which might hinder us (and compared we ported lots away from Qt to XCB during the Qt 5 porting removing the abstraction added by Qt). Oh and of course we will have to use Wayland directly, because we will have to use our own protocols for e.g. interfacing with Plasma. Which would mean that we have to interact with two technologies instead of one. Overall I didn’t see an advantage and that’s why KWayland is a facade over Wayland and not over QtCompositor.

What about (lib)weston

“But Martin”, you say, “you could integrate (lib)weston’s backend!”. Yes, weston uses plugins for it’s backends, so in theory it would be possible to load the plugins and interface with them. There were also patches to make this possible through a libweston, but I actually don’t know whether they got integrated (quick check looks like they didn’t).

I would love to have a library which abstracts e.g. kms or framebuffer for me, but honestly I doubt weston is that. Weston was developed as the reference compositor and not as a library to do that. Weston code is always open in my editor, so I know a little bit about the code and can see that it is – well – Weston-specific. I doubt that the code base could be shared in it’s current state. It would need an effort like what has been done for libinput to move this into a well designed API. As long as that doesn’t happen weston’s backends are not directly useable for us.

And even if we would get back to a different feature set. We use QPainter for non-GL rendering, Weston uses pixman. And that is nested into the compositor implementations of Weston. Again: that needs lots of work to get in a state which would allow integration, so overall it’s not a “just use it”.

And all of that does not consider what is more difficult: integrating the C API or writing the code yourself tailored in a way which makes sense in a C++/Qt world.

Posted on

KWinception

Last week I merged in a few important changes for the upcoming KWin 5.3 release. The rootless Xwayland support is integrated, which means we are a huge step closer to managing Wayland clients. Rendering, input and cursor is already using the Wayland code paths and will be shared with proper Wayland clients. I have already started working on code for that and have it working quite nicely already but decided to delay the integration for Plasma 5.4.

This means that kwin_wayland starts a Wayland server, but except Xwayland there is no application which can properly connect to it. Nevertheless it’s an important step and allows to also test the code in a better way.

In addition I worked on a better support for nesting compositors. So far one had to start Weston in order to test kwin_wayland. This is of course not optimal as it makes the development setup more difficult than it has to be. So last week I looked into developing a new backend which can use an X11 window to render to. This is comparable to Weston which can be used nested on X11. The backend is relatively straight forward: it can render to the created window using either the OpenGL or QPainter compositor, accepts input events and delegates them and passes the cursor from Wayland windows to the X11 window. The tricky part is that we cannot use any of our X11 specific libraries to create the window: we don’t use the xcb QPA, so no support from Qt and we cannot use KWindowSystem as it only allows one xcb_connection and that’s already needed for the Xwayland window manager. So I had to do things myself and as I consider this just a development feature it’s probably the worst X11 client in existance 😉 (Long term KWindowSystem should be changed to support multiple connections, would be very useful for unit tests).

The new backend triggered a small refactoring which makes it easier to implement further backends like e.g. a plain framebuffer or a drm/kms. As a small reminder: there’s an open GSoC idea for implementing the drm/kms backend and application period is to close soon.

Anyway with the nested KWin it’s now possible to create a kwin_wayland instance on the X Server using kwin_x11 and on the kwin_wayland one can create yet another kwin_wayland so that we have a KWinception:

Aus 2015-03-19

To start such a nested compositor use:

kwin_wayland --windowed --xwayland

Please watch the debug output for:

X-Server started on display :1

This tells the id of the created X Server (normally the next free id) and allows to start an application on the nested KWin:
DISPLAY=:1 kwrite

KWin_Wayland picks the windowing system depending on the environment variables which are defined. For DISPLAY it uses X11, for WAYLAND_DISPLAY it uses Wayland. If both are defined Wayland is preferred. If one wants to specify explicitly one can use the command line arguments –x11-display or –wayland-display. E.g.


kwin_wayland --windowed --xwayland --x11-display=:0

For X11 there are also the options –width and –height to specify an initial size (default is currently 1024×768). On Wayland these options are currently not available, the window always opens fullscreen.

Please remember that this is pretty new code and the support is still incomplete. Feature might be missing or broken. This is at the current state expected and because of that we do not yet accept bug reports. If you find a bug which you think should be fixed, please open an editor 😉

Posted on

Rootless Xwayland server integration into KWin

Over the last weeks I concentrated my KWin related work on trying to integrate the Xwayland server properly. Xwayland is an interesting step on the way to Wayland as it maps X11 windows to Wayland surfaces. But it also needs an X11 window manager to manage the X11 windows. Overall it allows us to start integrating Wayland into the compositor without too much breakage. It’s still X11 after all, so our existing code base continues to work. And gruadually functionality can be replaced with the Wayland equivalent, so that we can afterwards start integrating proper Wayland clients.

Integrating Xwayland showed interesting challenges. KWin as an X11 window manager requires a running X server prior to start. It also can only communicate with one X server, the code base has many hard constraints on being only one X server. This means if we want to use Xwayland the Xwayland server must be the one KWin uses. Which means Xwayland must be started prior to KWin’s X11 usage. So far KWin also enforced the usage of the “xcb” QPA plugin, the windowing system abstraction plugin for the X world in Qt. This plugin gets loaded directly at application startup and aborts if there is no X server it can connect to.

As you can see KWin needs to ensure that Xwayland is running prior to the application startup. But Xwayland requires a running Wayland server, which is supposed to be provided by KWin and for processing Wayland events we need a running event loop, which is only present after the application started. Looks like we are caught in a dependency loop:
circular-dependencies

After some hacking and experimenting I found a solution which can start the Wayland server and Xwayland prior to the application startup, but it’s considerable fragile and it can only be a temporary solution. In the long run it would of course be better if KWin could use the Wayland QPA plugin provided by QtWayland to connect to it’s own Wayland server and start Xwayland later-on.

Nevertheless I succeeded in getting KWin connect to the Xwayland server and to start transitioning X clients to be rendered using Wayland buffers instead of performing texture from X11 pixmap:

Aus 2015-02-11

But it just hit another problem: it didn’t support accelerated OpenGL rendering on the X server. That’s quite a problem if no X11 client connected to the Xwayland server can use proper OpenGL and it’s even a problem for KWin as KWin uses QtQuick scenes which use the X server. So KWin itself fails to render accelerated UI. Compositing is not affected as we don’t use Qt for that.

The reason for the problem is that Xwayland expects the Wayland “wl_drm” interface to be present. This interface gets created when binding an EGLDisplay to a Wayland display. In case of KWin the EGLDisplay exists after the Compositor is fully initialized. And again we are in a dependency chain: the Compositor gets created and uses the Workspace class. This class controls the complete startup of the X11 window manager which means it’s highly X11 dependent and requires Xwayland to be present. Again we are in a dependency loop.

Breaking up this dependency loop is quite tricky. The Compositor is too deeply nested into the application to be considered started before creating the QApplication. This means we must be able to create the QApplication before we have an X Server running. This means no usage of xcb QPA plugin. As KWin is going to start a Wayland server anyway, it would be good to get KWin to use the wayland QPA plugin.

This was again quite a challenge. The QtWayland QPA plugin performs blocking roundtrips to the Wayland server in the main thread during startup. But the Wayland server is running in the same thread. So a blocking call to the Wayland server dead locks the server. It’s not possible to move the Wayland server at that point into a thread as one cannot start a QThread prior to having the QCoreApplication created.

The solution I developed for this problem involves creating an own event dispatcher prior to creating the QApplication. So we have the event dispatching for the Wayland server ready to use. Just the event loop is not yet running. This allowed to provide a small patch for QtWayland to run any event dispatcher set before creating the QApplication. A test application in the kwayland repository is also adjusted to make use of it (the test application is also able to start an Xwayland server prior to creating the QApplication).

Unfortunately there is still another issue: QtWayland might call eglInitialize in the main thread which again performs a blocking wayland call. This is a problem I haven’t solved yet and currently just hacked around by disabling OpenGL in Qt (which breaks the QtQuick views).

Being able to use the Wayland QPA just creates a new bunch of problems for KWin. KWin still needs to use X11 and thus needs to create an xcb connection. Just that this wouldn’t help much. KWin on X11 doesn’t init the xcb connection, it’s the xcb plugin in Qt which does it and we only access it via QX11Info. Thus KWin needs to be moved away from the usage. Luckily in many cases we already wrapped the functionality as going through the QPA interface (which QX11Info does internally) is too expensive for our use cases. So the changes are not that invasive. But KWin also uses frameworks like KF5WindowSystem which use QX11Info. Even more those frameworks were properly fixed to perform platform checks and don’t do the X11 specific code if it’s not on platform xcb. But it’s providing important X11 window manager functionality for KWin. For some classes like KWindowInfo and KWindowSystem the fix was trivial: don’t use in KWin. There’s also the more low-level NETRootInfo and NETWinInfo and that’s what KWin should use – usage of the KWindowInfo or KWindowSystem inside KWin can be considered a bug. For some other classes it was already partially possible to be used without the xcb plugin on X11. The classes are only used if we compile with xcb present, so it was possible to add more xcb specific methods which can then be used by KWin even if we do not use platform xcb. The required changes will be part of frameworks 5.8 release.

To summary where we are now: we can start kwin_wayland on platform wayland connecting to a Wayland server started by kwin_wayland, we do not require QX11Info in (most of) KF5WindowSystem and KWin. We are a good step closer to the aim, but still not there. The dependency loop is still in place: Workspace starts the Compositor, the Compositor creates the EGLDisplay which is needed to start Xwayland, which provides X11 which is needed for starting the Workspace.

This means: reorder the startup. We need to be able to start the Compositor prior to the Workspace (which could be interesting for kwin_x11, too, as it could improve persumed startup time). This task was easier than expected. Workspace got split into many modules over the last years and most modules which need to be created prior to creating the Compositor do not depend on Workspace and do not depend on X11. In the few cases where it actually does depend on X11 it was not difficult to delay the X11 specific code till after the X11 connection is created.

With all that in place I was able to delay starting Xwayland to after the Compositor is created and Xwayland can provide OpenGL to the connected clients:

This screenshot shows kwin_wayland running on top of Weston connected to an Xwayland server supporting proper OpenGL as can be seen by the output of glxinfo (in the konsole) and glxgears. Also plasmoidviewer just works on top of this X stack.

Of course there is still some work to be done till this is production ready code, but it looks really promising and I hope to have this ready for the KWin 5.3 release. The aim is also to get more and more features changed to use the Wayland functionality instead of the X11 functionality. E.g. for damage event handling it already uses the damage event of a wl_surface instead of creating an X11 damage handle. This makes supporting Wayland clients easier afterwards.

Posted on

Libinput integration in KWin/Wayland

Today I pushed my outstanding branch to get libinput support into kwin_wayland. Libinput is a very important part for the work to get a full Wayland session in Plasma which means we reached a very important milestone. As the name suggests it allows us to process input events directly. KWin needs to forward the input events to the currently active application(s) and also interpret them before any other application gets them. E.g. if there is a global shortcut KWin should intercept it and not send it to an application.

Why libinput integration in KWin?

KWin/Wayland already supported input handling by being a Wayland client and connecting to a Seat. But especially for pointer events this was not sufficient at all. We have quite some code where we warp the pointer and Wayland doesn’t support this (and shouldn’t). Warping the pointer is normally considered evil as it can introduce quite some problems if applications are allowed to warp the pointer. E.g. it can create security issues if you start typing your password and a malicious applications warps the pointer to trick you entering your password into a password field of the malicious application. Also from a usabililty perspective it can be problematic as it makes the system behave in an unpredictable way.

On the other hand if the application is a window manager/compositor the need for warping cursors arises. For example the screen edge handling pushes the cursor slightly back which needs cursor warping. Or you can move a window with the cursor keys (hold Control key to have very precise moving) and in these cases we need to warp the pointer. With libinput this is possible again as KWin gets put in control of the input events directly. It completely bypasses the currently used Wayland compositor.

Libinput is also an important piece in the puzzle for a full Wayland session which does not rely on another Wayland compositor. So far KWin/Wayland can only be used in a nested scenario – which is important for development and interesting new possibilities like the idea for a SoK project – but we also want full support without the need for a Wayland session. 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 😉

The merged implementation does not support all of libinput yet. Most important touch screen support is omitted as I don’t have a touch enabled device. I plan to sit down with fellow KDE developers who have a touchscreen enabled device and implement that part together. Also I will contact the VDG to define some global touch gestures to interact with the system (I’m quite interested in having a touch gesture to activate Present Windows). There’s lots of work to be done here and I would welcome any helping hand.

Security challenges

Processing input events directly comes with a slight problem, though: one needs to be root to read the events. And that’s obviously an absolute no-go for KWin. KWin may never ever be executed with root privileges and also not an suid which drops privileges again (which also wouldn’t help in that case but so what). The application has not been designed for running as root. The same is the case for Weston and obviously I looked at how it’s solved there and there is a very neat solution to support the use case we have in logind. The session controller can ask logind to open devices and logind provides a file descriptor to the opened device. In addition logind automatically takes care to close the file descriptors when a VT switch happens, which is extremely convenient for the use cases of Wayland compositors. So obviously I went for this solution as all it needs is connecting to very few D-Bus calls. This means the libinput integration in kwin_wayland will have a runtime dependency to a logind D-Bus interface. Of course this does not affect kwin_x11, neither does it affect kwin_wayland without libinput integration, but of course without libinput you won’t get support for all features. There is one caveat though: logind will blank the VT when the session controller goes away. So make sure to not run kwin_wayland with libinput support on your primary X session. Because of that libinput support must be explicitly enabled with the –libinput command line switch of kwin_wayland.

Current state and downsides of libinput and logind

As libinput does not yet have a stable release, the dependency is still optional and it’s possible to build kwin_wayland without libinput support. This is currently very important for the non-Linux operating systems, which might want to provide kwin_wayland, as libinput only supports Linux.

I hope that libinput will become available on other platforms. At XDC during the BSD presentations I heard at least one presenter touch the topic. So I’m optimistic that in the long run this will happen as we also see that DRM and KMS is nowadays in quite a good shape on the BSDs. For KWin development it’s of course important that we have only one library to interact with. Otherwise it means platform dependent code which is hard to develop and extremely difficult to test for the main developers not using such a platform. So if you want to get kwin_wayland on non-Linux, please consider putting the energy into getting libinput working (challenge is udev) as that will help all systems and not just KWin. After all we want to stand on the shoulders of giants 😉

Logind is in a similar situation. It is developed as a component in systemd, which isn’t available on all systems which run KWin. Luckily we don’t depend on logind directly but only use a subset of a well defined D-Bus interface and that interface can be provided by other tools as well. Something like that is already being worked on for the BSD’s.
Like with libinput, I would much prefer to keep KWin lean and efficient and not complicate the code base and development by including libraries for specific platforms or having security relevant code around. As written above: using suid wrappers is very much a no-no to me. But of course it would be possible to implement the subset of the D-Bus in an independent project and provide it. KWin would happily use it, it just needs someone to write the code. So if enough people care, I’m quite sure that there will be a developer stepping up and writing the code.

I decided to put out a small FAQ here for those who have questions about the implications of the above:

FAQ

Does that mean KWin (and Plasma) depend on systemd?

No.

But it depends on logind?

No. It uses one D-Bus interface provided by logind. It doesn’t care which program is providing this D-Bus interface. It can be logind or logind-shim or the implementation being worked on for the BSDs. Even a small binary just providing the used D-Bus interfaces would work.

You should not use logind, there must be a different solution!

I’m sorry I did not find any solution which was as efficient and secure as the one provided by logind. Of course there are solutions like weston-launch, but they introduce a lot of complexity – both on the coding side and on the installation side. As such a solution would need to be suid, I’m very reluctant to the idea. We shouldn’t introduce such possible security risks, if there are better solutions available. Logind is simply providing a feature which is needed by kwin_wayland.

Does that affect KWin on X11?

No, that only affects kwin_wayland.

But there is no logind for the BSDs! So I won’t be able to run kwin_wayland on BSD systems?

Unfortunately the fact that logind is missing is least of your problems on BSD. Logind support is only needed for libinput which right now is not available on BSD. The kwin_wayland binary on BSD will not try to interact with logind. I’m sorry I don’t have a solution for the input stack on BSDs. I really hope the BSD developers can come up with a solution for this as we don’t have the resources to build a separate input solution for one platform.

How can I change KWin to not use logind?

As I noted, it is important to me that KWin is secure and that the code base is as easy to understand as possible. I don’t like the idea of having ifdefs all over the place and multiple solutions as that results in bitrot. When I pushed the libinput change it directly failed to build on the CI system as the ifdefs introduced a variation which I couldn’t test on my system. Each ifdef and each platform-specific solution increases the development and maintenance costs significantly. This means that I will only accept patches which don’t introduce the above mentioned problems. Preferrable a small wrapper binary could provide the needed D-Bus interface for KWin and other applications which need this functionality. This would not need changes in KWin at all and would be from my perspective the perfect solution.

Why won’t you implement such a wrapper binary?

Honestly there are a million things I would do if I had time, but a day has only 24 h and I have to prioritize my work. Just check the Wayland TODO list for what we all need to do to get KWin/Wayland ready. Why don’t you open your editor and get some work done? 😉

But if KWin uses logind, Slackware will drop all of KDE!

Yes, I have read that (see comments). Luckily the situation for Slackware is similar to the BSDs: it doesn’t matter right now. Slackware doesn’t provide Wayland packages yet, so the logind support won’t be used as there is no kwin_wayland binary which could be built. And if enough people care, as I said, one or more of them can write the wrapper binary and KWin and other compositors will work just fine.

How can i help?

Best by writing code 🙂 See the TODO list I linked in an above answer. Also it would be good if someone documented the steps to get kwin_wayland running and how to develop on it cough.

Posted on

An Update on kwin_wayland

With the initial release of Plasma 5.0 behind us I also started to look more in the direction of Wayland again. Now I’m kind of in full flow on Wayland work and kwin_wayland is progressing nicely. Yes, KWin 5.1 will introduce a new binary called kwin_wayland to complement the kwin_x11 binary which got introduced in KWin 5.0.

Now I do not want to list all the changes as you can hardly express them all in a blog post, but I can point to my Akademy talk. I will provide a small overview of the current state, what is new in KWin 5.0, what will be new in KWin 5.1 and where the journey is going.

I'm going to Akademy 2014

Of course there is lots of work going on and help is always appreciated. We started to use a public available task tracker on todo.kde.org. Also I have to say that there are still quite some open tasks for kdecoration2. Please help as I cannot split myself and it would be super important to release KWin 5.1 with kdecoration2.

Posted on

Running frameworks powered applications on Wayland

After I got KWindowSystem to no longer require X11 on Linux I dared to start some of our applications which got ported to frameworks 5 with the magic “-platform wayland” command line switch. And look there: they started and were useable. But there were some obvious problems: e.g. our platform integration plugin was not loaded. But with a small change to Qt 5.3 this problem is solved. Now if you run a Wayland compositor in a KDE session you will get the KDE integration as one would expect. But this just openend a new set of problems: our default QStyle (Oxygen) was crashing any application on startup as it was still assuming that it’s on X11 if compiled with X11 support. Easy enough to fix and now Oxygen works as one would expect.

This experience highlighted an obvious problem: our applications will crash if they are compiled with X11 support and do not perform a runtime check. So I started to hunt down possible crashers in our libraries. In the perfect world there should not be any X11 specific code in the libraries (except KWindowSystems). And luckily our libraries supported non-X11 platforms for quite some time, so all the X specific code should be in HAVE_X11 blocks. So a small reminder for everybody who thinks that we should never have supported Windows in the first place: thanks to Windows support most of our applications just work on Wayland. Have a look at this nice collection of applications which are running just fine on Wayland:

Aus Weston

Right now we have reached a state where I am no longer able to crash applications at random and most applications which I give a try just work. We had a few problems in kde4support which prevented any applications which still used K(Unique)Application to start at all on Wayland and that framework had stronger usage of HAVE_X11 than I expected. Although the framework is deprecated I fixed all the issues I could find in it, to get applications to support Wayland faster. Basically if your application compiles on frameworks it will run on Wayland out of the box. Also thanks to that work our applications will just work on any proprietary windowing system (so no need to be upset that we put more work on e.g. Windows support than on your small pet project). My personal aim is to have Wayland support at least on par with Windows support in our first release of frameworks. Later on we will improve it to get it on the same level as X11 support.

Of course it’s possible that I haven’t spotten all crashes in the libraries yet. And I encourage our application developers to test their applications on Wayland. That’s quite simple in fact: just start Weston (can be nested in the X session) and prepare the setup:

source kf5_env.sh # your kf5 environment variables setup script
unset DISPLAY # to make sure that any XOpenDisplay call will fail
export WAYLAND_DISPLAY=wayland-0 # adjust to whatever you used in Weston

Now all you need is to pass “-platform wayland” to the command line args to start your application on Weston. In case you are using a KApplication and KCmdLineArgs you need to use “--platform wayland” instead. Update: as an alternative one can also export the environment variable “QT_QPA_PLATFORM” and set it to “wayland”. If you run into any problems with it, feel free to ping me on IRC. In case you get your application to crash in one of the frameworks and it’s a crash due to using X11, please report a bug and set me on CC. In case you hit a crash in your application there is a very easy pattern to solve the problem:

#if HAVE_X11
if (QX11Info::isPlatformX11()) {
    // do your X specific calls here
}
#endif

If you are not using QX11Info you can also do:

#if HAVE_X11
if (QGuiApplication::platformName() == QStringLiteral("xcb")) {
    // do your X specific calls here
}
#endif

As you can see it’s performing a string comparison so you don’t want to have that in a code path which gets called often. Recommendation: move it into a member variable which gets initialized only once in app life cycle and also ifdef the variable – no need to do these checks on e.g. Windows. If you have any questions with it, feel free to ask me.

In the workspace module I hit a few crashers in modules which make absolutely no sense on non-X11. The code is too X specific and most likely needs a complete rewrite if we want to have it on non-X11. Of course we don’t want to have modules which just crash in systemsettings. So I introduced a new method to KService to check whether the plugin makes sense on the current Qt platform. This is honored by ::noDisplay() so systemsettings (and also kcmshell5) won’t pick them. To specify one can use e.g.

X-KDE-OnlyShowOnQtPlatforms=xcb

in the plugin’s desktop file. There’s also a “X-KDE-NotShowOnQtPlatforms”.

Posted on

KWindowSystem in Frameworks 5

KWindowSystem is a tier 1 framework which allows to interact with the windowing system. Historically it provided an implementation of NETWM on X11. It provides a NETRootInfo for accessing the global state (all that’s set on the root window) and NETWinInfo for all information about a specific window. The classes have a window manager and client perspective. This is the foundation which powers our window manager and various parts of the desktop shell such as the taskmanager.

On top of those X11-specific classes we have a convenient API KWindowInfo and KWindowSystem which provides a windowing system independent API for our applications. Thus we have different implementations depending of the platform it’s compiled on. On X11 the implementation depends on named NET* classes, on Windows and Mac what makes sense is implemented using the platform specific API.

In the good old days of Qt 4 this was a sufficient solution. If it’s build on unix-like systems we have X11 and we know it’s X11, on Windows it’s Windows and so on. With Qt 5 this no longer works. Just because we built with X11 support doesn’t mean the software will run on X11. Due to the introduction of the QPA it’s possible that another platform is used – most obvious Wayland. But there are more platforms for Linux like Android. With the solution from Qt 4 our applications would just crash as soon as they access KWindowSystem as that tries to interact with XLib/xcb unconditionally.

Over the last weeks I spent quite some time on making sure that KWindowSystem works as expected (that is doing nothing at the moment) when run on Wayland. Just adding a new implementation as in the Qt 4 days is no solution as we want our framework to support both X11 and Wayland at the same time. Otherwise our distributions would have a hard time packaging our software. The approach was to introduce an internal abstraction in KWindowInfo and KWindowSystem and have a platform implementation. This is now done for X11 together with a dummy implementation which is used as a fallback if we do not have an implementation for the currently used windowing system (e.g. Wayland). Unfortunately this has a side-effect: it broke the backend for Windows and MacOS. I don’t feel very happy about it as I don’t like to break the work of others, but I cannot fix it. Windows and MacOS are proprietary systems for which either a license or even specific hardware is required. I do hope that the specific teams will re-add the support till the release of frameworks 5. Please note: at the time of writing this blog post not all patches are merged yet.

A nice side-effect for this work was that I started to write unit tests for KWindowInfo on X11. This is far from trivial as it interacts with X11 and the running window manager. And the test kind of depends on the used window manager. Obviously given that it’s KDE it would make sense to write the test against KWin, but that’s not sufficient for our CI system as kwindowsystem is a dependency of KWin and thus kwindowsystem cannot depend on KWin (not even on runtime). Thus the tests are now performed against openbox on the CI system, but also succeed when running against KWin. They are quite a stress test for a window manager and found one very unlikely crash condition in KWin (of course already fixed).

The framework provides more functionality which is kind of X11 specific. For example there is the KSelectionOwner and KSelectionWatcher which implements a manager selection as described in ICCCM, section 2.8. Again a very important building block for our window manager. While it’s clearly X11 specific code which only gets built if X11 is available, there is no reason to crash if it’s not run on X11. So I went through all of our sources and tried to make sure that it correctly checks whether the runtime platform is xcb. Thus we don’t have to change all applications using it, but can rely on the library not to crash. Still if your application is using these X11 specific functionality I highly recommend to check for the platform as you might run into runtime errors. E.g. claiming a manager selection will fail, don’t rely on it.

As all of this is kind of a requirement to running frameworks based applications on Wayland, I have to do the obligatory screenshot of Kate on Weston:

Aus Weston
Posted on

An unexpected journey

Since my last post quite some progress has been made in getting KWin working on top of a Wayland compositor. My main focus of work has been on the input stack. This is something I am not really familiar with as so far we did not have to care about it.

As some might know input handling in X11 is very insecure. Every application is able to listen to every key event. And in the KDE workspaces we obviously make use of these “features”. For example the global shortcut handling is implemented as a kded module listening to all key events and notifying the application via D-Bus that the shortcut got triggered. In a post-X11 world this will not work any more: applications are no longer able to listen to all key events.

One of the important tasks therefore is to not send all input events to the
X-Server but just to the window which should get it, or to handle the input events inside KWin and discard them without passing to the applications. My current branch already supports activating screen edges and using fullscreen effects like Present Windows completely without passing the input events through X. This means that some of the longstanding issues are automatically resolved. We no longer “steal” the screen edges from applications and starting the screen locker should be possible even if present windows is active (not tested and still needs some screen locker support in KWin).

But this also means that features like the global shortcut handling start to break. Mostly because kded is not listening on my virtual X but that’s just detail 😉 So I also had to start working on global shortcut support inside KWin – otherwise I would have had a hard time to use some of the important features like switching desktops or using Alt+Tab. At the moment the latest code only supports KWin’s internal shortcuts, but global support for kglobalacceld will have to follow. We had some ideas on how to improve global shortcut handling in general anyway.

When the infrastructure was in place I couldn’t resist the temptation to work on features which had been requested for a long time and were not really possible to do with X11 (or only with huge hacks): mouse shortcuts. Ctrl+Alt+left click activates desktop cube. But that’s not enough. While sitting in the Kubuntu Developer Summit I added also mouse wheel support which allows us to ctrl+alt+wheel to switch desktops and also to use the zoom effect. This work can be found in branch kwin/global-shortcuts on my personal workspace clone.

I hope that we will soon have a decision on the “what’s master” discussion and I can start merging the changes in. Once this is done I plan to switch focus to the Qt 5 port and concentrate on this for the next few weeks.

Nevertheless this should not be a reason to stop the work on the Wayland efforts. There are so many small things which can be done and lots of low hanging fruit. I will try to setup a trello board with a few tasks, so that interested developers could start picking up some easy tasks and get their hands dirty. Once something is in place I’ll write another post.

Posted on

More Software Compositing

One of the most often repeated misconceptions about Wayland is that it requires hardware acceleration. I would have thought that this issues would have been resolved once the reference compositor, Weston, supported rendering through Pixman. The reason for this misconception is most likely that the earlier versions of Weston required hardware acceleration.

Now KWin in 4.11 introduces the same mistake. Our experimental Wayland support is only available in the OpenGL compositor – even OpenGL ES is not supported (something is broken on my system I cannot start it). I think this is a bad situation. One of the huge advantages of KWin is the exchangeable compositor allowing to switch to software based XRender in case there are no proper drivers available. In fact KWin switches automatically to XRender if it detects a driver which recommends the XRender backend (e.g. software rasterizer).

So last week I started to work on some new Wayland related features and extended the XRender compositor in a way that it renders to a Wayland surface. It’s a pretty simple setup. Our XRender compositor uses an off-screen pixmap for rendering. The adjusted backend uses a pixmap created through XShm, so we get the frame rendered into a shared memory segment. From there we just copy it into a shared memory Wayland buffer to share it with the Wayland compositor. It would be better if we could create the shared Wayland buffer directly from the XShm segment, but I did not see a solution on how to achieve this.

In the end it’s also not really relevant. After all we want to use Wayland and the last thing we want to do on Wayland is using an X11 rendering API for compositing. So we can consider this more as a proof-of-concept and as a task so that I can get more familiar with Wayland 😉 It helped me to improve the code, so it was worth the effort. Even if it is a more academic solution it serves a concrete use-case: KWin uses XRender as a fallback and we can expect that the backend works. Given that we have to enforce compositing in future, it’s good to know that all backends work. The current state of this work can be found in branch kwin/wayland-backend of my clone (note: the link might change in case I force push).

Video on YouTube

If XRender is an academic solution, we are still facing the problem that we lost our software compositor. So I thought I need to also do something about this problem and started to work on a new compositing backend based on QPainter. It’s a quite simple compositor which uses a QImage as the rendering target. The QImage is created directly from the Wayland buffer, so in opposite to the XRender backend we don’t have the needless memory copy from one to another buffer. This is a very interesting compositor as it’s the first part of KWin which has been written from scratch only with Wayland in mind. It doesn’t support X11 (at the moment). This is the first new compositor written in years, so I found some things to improve and which are already under review. And as it was much easier to write a new compositing backend than I expected, I decided to document it in our wiki. It would be totally awesome if someone could have a look at it and write a dedicated compositor for the RaspberryPi 😉 The new compositor can be found in branch kwin/qpainter-scene.

The switch to Wayland does not only affect our software compositors, but compositing in general. So far KWin has always had the possibility to not require compositing. This doesn’t make any sense in a Wayland world. So I needed to teach KWin that we might need to enforce compositing. Of course on X11 we still want to have the option to disable compositing, so the changes only affect the Wayland backend. When starting KWin with the Wayland display environment variable set, KWin will require compositing. Even if it is disabled in the config options it will be enabled. Even more it ignores the shortcut to suspend compositing and options like unredirection of fullscreen windows. But still the backend might fail and in this case KWin is just exiting. There is no need to continue execution if one cannot see the output. This work can be found in branch kwin/enforce-compositing (which also contains all the other mentioned branches).

Posted on

Starting a full KDE Plasma session in Wayland

This week there will be the release of KDE SC 4.11 Beta 1 and this will come with an interesting new feature: an experimental Wayland backend inside KWin. This backend does not allow to manage Wayland clients, but uses another Wayland compositor as the rendering target. Instead of rendering to an X window, KWin renders to a Wayland surface. From an architecture point of view this means that there is a Wayland system compositor and KWin is running as a Wayland session compositor (although KWin is not yet a Wayland compositor).

Disclaimer: this is a highly experimental feature and not intended for productive usage. Please do not report any bug reports in the bug tracker. If you find an issue please open your editor, hack and submit a review request.

Now I expect that you are also excited about Wayland and that you want to run your KDE Plasma session on top of Wayland instead of X, right? So here are the instructions: First of all you need to change the “Tearing Prevention (VSync)” in KWin’s Advanced desktop effects settings to “Full scene repaints”. This is needed because KWin does not yet support the buffer-age extension needed to properly repaint in Wayland. Note: when using X11 you probably don’t want to use this option, it wastes quite some power.

The KDE Plasma session startup is controlled by a script called “startkde”. In order to start the KDE Plasma session with Wayland we also need this script, but need to have a few environment variables set to tell KWin that it should use Wayland. So best copy this script and call it” startkde-wayland”. Edit this file and add the following exports after the shebang:

export DISPLAY=:99
export WAYLAND_DISPLAY=wayland-system-0
export KWIN_OPENGL_INTERFACE=egl_wayland

Now all we need is another small shell script to start Wayland, Xvfb and the modified startkde script. Let’s call it kwayland:

#!/bin/sh
weston-launch -- --socket=wayland-system-0 &
Xvfb -screen 0 1366x768x24 :99 &
startkde-wayland &

Please change the screen resolution to the one used by your screen. KWin is not yet able to update the resolution of the X server to what Weston uses. This also means that you cannot change the resolution or add multiple screens (as I said: it’s an experimental feature).

Now log out of your running KDE session, switch to a tty and stop the still running X server. With X out of the way you can start the kwayland script. You should see Weston starting and shortly afterwards KWin should take over. If everything is configured correctly you should see the normal splash screen (seems like my system is not configured correctly).

Once the system is fully started you can just use it. If everything works fine, you should not even notice any difference, though there are still limitations, like only the three mouse buttons of my touchpad are supported 😉 I would post a screenshot but it’s fairly uninteresting as one cannot see a difference.

This blog post was written in a KDE Plasma session running in Wayland.