Why does kwin_wayland not start?

From time to time I get contacted because kwin_wayland or startplasmacompositor doesn’t work. With this blog post I want to show some of the most common problems and how to diagnose correctly what’s going wrong.

First test nested setup

If you want to try Wayland please always first try the nested setup. This is less complex and if things go wrong easier to diagnose than a maybe frozen tty. So start your normal X session and run a nested KWin:
export $(dbus-launch)
kwin_wayland --xwayland

This should create a black window. If it works you can send windows there, e.g.:
kwrite --platform wayland

When things go wrong

Xwayland missing

KWin terminates and you get the error message:

FATAL ERROR: failed to start Xwayland

This means you don’t have Xwayland installed. It’s a runtime dependency of KWin. Please get in contact with your distribution, they need to fix the packaging 😉

Application doesn’t start

KWin starts fine but the application doesn’t show because of an error message like:

This application failed to start because it could not find or load the Qt platform plugin “wayland”in “”.

Available platform plugins are: wayland-org.kde.kwin.qpa, eglfs, linuxfb, minimal, minimalegl, offscreen, xcb.

Reinstalling the application may fix this problem.

This means QtWayland is not installed. Please install it and try again.

Platform plugin missing

KWin terminates and you get the error message:

FATAL ERROR: could not find a backend

This means that the platform/backend plugin is not installed. KWin supports multiple platforms and distributions put them in multiple packages. For X11 you need e.g. on Debian based systems the package kwin-wayland-backend-x11. For the “real thing” you need: kwin-wayland-backend-drm.

XDG_RUNTIME_DIR not set

KWin terminates and you get the error message:

FATAL ERROR: could not create Wayland server

This means that KWin failed to create the Wayland server socket. The most common reason for this is that your environment does not contain the XDG_RUNTIME_DIR environment variable. This should be created and set by your login system. Please get in contact with your distribution. The debug output should also say something about XDG_RUNTIME_DIR.

Platform fails to load

KWin terminates and you get the error message:

FATAL ERROR: could not instantiate a backend

You hit the jackpot. Something somewhere went horribly wrong. Please activate all KWin related debug categories, run it again and report a bug against KWin – ideally for the platform you used. The debug output hopefully contains more information on why it failed. If not we need to try to look into your specific setup.

Trying on the tty

KWin works fine in the nested setup: awesome. In most cases this means that KWin will also work on the DRM device. Before trying: make sure that you don’t use the NVIDIA proprietary driver, if you do: sorry that’s not yet supported. If you are on Mesa drivers everything should be fine.

Log in to a tty and setup similar to nested setup – I recommend the exit-with-session command line option to have a nice defined setup to exit again:

export $(dbus-launch)
export QT_QPA_PLATFORM=wayland
kwin_wayland --xwayland --exit-with-session=kwrite

Ideally this should turn your screen black, put the mouse cursor into the center of the screen and after a short time show kwrite. You should be able to interact with it and when closing kwrite KWin should terminate. If that all works you are ready to run startplasmacompositor. It will work.

But what if not. This is the tricky situation. The most often problem I have heard is that KWin freezes at this point and gdb shows KWin is in the main event loop. This most likely means that KWin tries to interact with logind DBus API, but your system does not provide this DBus interface. Please get in contact with your distribution on how to get the logind DBus interface installed (this does neither require using systemd nor logind). I would like to handle this better, but I don’t have a system without logind to test. Patches welcome.

Running KWin on the weird systems

Yes one can go crazy and try running KWin on devices like the Nexus 5, Virtual Machines or NVIDIA based systems. Here the experience differs and I myself don’t know exactly what is supported on which hardware and in which setting combination. Best get in contact with us to check what works and if you are interested: please help in adding support for it.

Animating auto-hiding panels

With Plasma 5 a change regarding auto-hiding panels was introduced. The complete interaction was moved from Plasma to KWin. This was an idea which we had in mind for a long time. The main idea is to have only one process to reserve the interaction with the screen edges (which is needed to show the panel when hidden) and to prevent conflicts there. Also it allowed to have only one place for providing the hint that there is the panel.

On an implementation level that uses an x11-property protocol between KWin and Plasma to indicate when the panel should be hidden. KWin then does the interaction to hide it and to show on screen edge activation.

Unfortunately from a visual perspective this created a regression. In Plasma 4 the auto-hiding panel was animated with our Sliding-Popups effect, but in Plasma 5 this doesn’t work any more. The reason for that is that our effect system can only animate when a window gets mapped and unmapped. With the new protocol the window doesn’t get unmapped when hidden and not mapped when shown, so our effects are not able to react on it. Technically our Client object is kept instead of being released on unmapped.

Thanks to Wayland this will be working again starting with Plasma 5.8. For Wayland windows KWin keeps the object around when a window gets unmapped and uses the same object when it gets shown again. KWin keeps more state for Wayland windows than for X11 windows. But this also means that our animations are not working for Wayland windows. Last week I addressed this and extended the internal effects API to also support hiding/showing again of Wayland windows. As the effects API does not differentiate between Wayland and X11 windows this change also enables the auto-hiding panel animation. All that was needed was emitting two signals at the right place.

Here Wayland shows another strength: not only does it help to bring features to X11 it also allows us to automate the testing. With a pure X11 system we would have had a hard time to properly auto-test this. But for Wayland we have a nice isolated integration test-framework which allowed to add a test-case for auto-hiding panels.

Multi-screen woes in Plasma 5.7

With Plasma 5.7 we promised improved multi-screen support. While we achieved that, some users are still experiencing issues. This is unfortunate and our users have all the reasons to be disappointed with us. We are working very hard to fix the issues which have been reported to us since the release.

But there are many situations where users blame us for issues not under our control. With this blog post I want to describe some of the problems we got reported and explain them.

Display hardware key not working

In Bug 365147 a user reported that the notebook hardware key does not work. This is rather surprising as our code of course supports the key and it is working on the systems we developers have. We asked the user to run xev and report back what it prints when pressing the key. It turns out it sends Windows+P which is used since Windows 7. That is a rather unfortunate situation and I can only conclude that the hardware is broken. More information on this topic by Matthew Garrett. Although this problem had been described a few years back, we just had not been aware of it. We now fixed it by adding support for this shortcut. I’m not happy about that as it “steals” a shortcut, but that’s the best we can do in the case that a monopolist dictates a shortcut and hardware vendors follow.

Windows shown on incorrect screen

Matlab splash screen shown in non-visible area

One issue which got reported to me by a fellow KDE developer on Thursday was Matlab’s splash screen partially being positioned in an offscreen area in a multi-screen setup. To me as KWin maintainer and knowing how we position windows I knew that it is not our fault. Nevertheless we investigate.

First of all Matlab does not set the window type splash on it’s splash window. If it did KWin would position it on the center of the screen and also would support hiding it if one clicks on it. By setting the wrong window type KWin does not know that it’s a splash screen window and cannot apply the proper handling.

But there are more issues with that window. In addition the window contains a placement hint. This is described in the Inter-Client Communication Conventions Manual Section 4.1.2.3. In this specific case the window indicated that it got positioned by a user. To quote: “which allow a window manager to know that the user specifically asked where the window should be placed”. Of course the user does not specify the position of a splash screen outside the visual area. But Matlab tells us so, it’s clearly wrong, but KWin cannot know that. Instead it follows what the window requests: if the window indicates that it has a position, KWin honors that. The assumption is that the application knows what it does – apparently we are wrong here.

Skype notification window outside visible are

I also got a report about skype notifications being shown outside the visual area or in general on the wrong screen. This is something which we have even less control over. Let’s have a look at the xwininfo of a skype notification:

xwininfo: Window id: 0x1000129 "skype"

Absolute upper-left X: 1011
Absolute upper-left Y: 962
Relative upper-left X: 1011
Relative upper-left Y: 962
Width: 268
Height: 61
Depth: 24
Visual: 0x27
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x26 (installed)
Bit Gravity State: NorthWestGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: yes
Map State: IsViewable
Override Redirect State: yes
Corners: +1011+962 -1921+962 -1921-57 +1011-57
-geometry 268x61+1011-57

The important part is “Override Redirect State: yes“. This means that the window actively disabled the window manager on it. Of course the application should be doing the right thing, but sometimes they aren’t. In the case of Skype there is of course nothing we can do about it as it’s a proprietary application.

Of course the best way to fix this from Skype site would be to use the freedesktop specification for notifications. That way they don’t need to care about positioning windows correctly. It would go to experts.

Comboboxes/Menus shown on wrong screen

A few users reported that the comboboxes and menus of applications show on the wrong screen.
Menus placed on wrong screen

This problem is similar to the Skype notification issue. The windows in question are override redirect windows. The window manager is not controlling them. It’s the task of the toolkit to handle this correctly. Unfortunately Qt seems to have problems with it. To make it quite clear: this is a bug the Qt developers have to fix. It’s affecting all Qt applications on X11 and has nothing to do with Plasma. Just because Plasma is also using Qt does not mean that Plasma developers have to fix it. This is a bug the Qt developers have to fix. It’s embarrassing, not just for us, but for all applications built upon Qt – be it free software or proprietary. A combobox or menu opening on the wrong screen is an absolute no go. In my opinion that’s a showstopper bug. Unfortunately in such cases KWin cannot help to fix it.

Newly opened windows not placed on the primary screen

Many users expect that new windows open on the primary screen. Unfortunately primary screen does not imply that, it’s only a hint for the desktop shell where to put it’s panels, but does not have any meaning for normal windows.

Of course windows should be placed on a proper location. If a window opens on a turned off external TV something is broken. And KWin wouldn’t do so. KWin places new windows on the “active screen”. The active screen is the one having the active window or the mouse cursor (depending on configuration setting). Unless, unless the window adds a positioning hint. Unfortunately it looks like windows started to position themselves to incorrect values and I started to think about ignoring these hints in future. If applications are not able to place themselves correctly, we might need to do something about it.

Of course KWin allows the user to override it. With windowing specific rules one can ignore the requested geometry.

Please report your bugs

We saw many users complaining on social networks about the state of multi-screen. Please report the issues to us. It’s really important that we get to know the setups which don’t work. Yes of course it’s not acceptable if a hardware key doesn’t work, but if we don’t know about it there is nothing we can do to fix it.

We are also a little bit disappointed that users started to complain after the 5.7 release instead of testing our beta. It’s not difficult to try a live image to see whether an issue is resolved and then reporting a bug. It might even be less work than ranting on social media.

Why is multi-screen so difficult?

As a last point I want to discuss why multi-screen is difficult. It’s not like we KDE devs don’t have multi-screen setups (typing on one right now, though on Wayland) and don’t test our code. At the openSUSE conference a part of my talk was about the difficulty to test multi-screen. I think it’s valuable to share this here as well.

Lack of XRandR in virtual X servers

On X11 one has the XRandR extension to configure multi-screen. In addition there is also the legacy Xinerama and even more legacy neither-nor. For XRandR there are multiple protocol versions with different versions being incompatible to each other. Nowadays we can luckily assume that users have version 1.4 of XRandR – this is already quite an improvement compared to the past.

Unfortunately virtual X servers such as Xvfb lack proper XRandR support. Until recently Xvfb did not have the XRandR extension at all. So with Xvfb it was not possible to setup a test environment to test multi-screen code. Nowadays that’s supported but it’s still rather useless. Let’s have a look at the output of xrandr:

xrandr: Failed to get size of gamma for output screen
Screen 0: minimum 1 x 1, current 1280 x 1024, maximum 1280 x 1024
screen connected 1280x1024+0+0 0mm x 0mm
1280x1024 0.00*

We see that we only have one resolution on the screen, which does not have a physical size. This makes it impossible to test things like DPI (would require physical size), changing of modes, etc. Also hotplugging/unplugging of additional screens cannot be simulated that way. The situation is similar for other solutions like Xephyr and even Xwayland:

Screen 0: minimum 320 x 200, current 3200 x 1080, maximum 8192 x 8192
XWAYLAND0 connected 1280x1024+0+0 340mm x 270mm
1280x1024 59.89*+
XWAYLAND1 connected 1920x1080+1280+0 520mm x 292mm
1920x1080 59.88*+

The Wayland display reports the following information for the same setup:

interface: 'wl_output', version: 2, name: 16
x: 1920, y: 0, scale: 1,
physical_width: 340 mm, physical_height: 270 mm,
make: 'GSM', model: 'L1953T/308042',
subpixel_orientation: unknown, output_transform: normal,
mode:
width: 1152 px, height: 864 px, refresh: 75.000 Hz
mode:
width: 1024 px, height: 768 px, refresh: 75.029 Hz
mode:
width: 1024 px, height: 768 px, refresh: 60.004 Hz
mode:
width: 832 px, height: 624 px, refresh: 74.551 Hz
mode:
width: 800 px, height: 600 px, refresh: 75.000 Hz
mode:
width: 800 px, height: 600 px, refresh: 60.317 Hz
mode:
width: 640 px, height: 480 px, refresh: 75.000 Hz
mode:
width: 640 px, height: 480 px, refresh: 59.940 Hz
mode:
width: 720 px, height: 400 px, refresh: 70.082 Hz
mode:
width: 1280 px, height: 1024 px, refresh: 60.020 Hz,
flags: current preferred
interface: 'wl_output', version: 2, name: 18
x: 0, y: 0, scale: 1,
physical_width: 520 mm, physical_height: 292 mm,
make: 'SAM', model: 'SyncMaster/1263088180',
subpixel_orientation: unknown, output_transform: normal,
mode:
width: 1920 px, height: 1080 px, refresh: 60.000 Hz
mode:
width: 1920 px, height: 1080 px, refresh: 50.000 Hz
mode:
width: 1600 px, height: 1200 px, refresh: 60.000 Hz
mode:
width: 1680 px, height: 1050 px, refresh: 59.883 Hz
mode:
width: 1280 px, height: 1024 px, refresh: 60.020 Hz
mode:
width: 1440 px, height: 900 px, refresh: 59.901 Hz
mode:
width: 1280 px, height: 960 px, refresh: 60.000 Hz
mode:
width: 1280 px, height: 800 px, refresh: 59.910 Hz
mode:
width: 1280 px, height: 720 px, refresh: 60.000 Hz
mode:
width: 1280 px, height: 720 px, refresh: 59.940 Hz
mode:
width: 1280 px, height: 720 px, refresh: 50.000 Hz
mode:
width: 1024 px, height: 768 px, refresh: 60.004 Hz
mode:
width: 800 px, height: 600 px, refresh: 60.317 Hz
mode:
width: 800 px, height: 600 px, refresh: 56.250 Hz
mode:
width: 720 px, height: 576 px, refresh: 50.000 Hz
mode:
width: 720 px, height: 480 px, refresh: 60.000 Hz
mode:
width: 720 px, height: 480 px, refresh: 59.940 Hz
mode:
width: 640 px, height: 480 px, refresh: 60.000 Hz
mode:
width: 640 px, height: 480 px, refresh: 59.940 Hz
mode:
width: 1920 px, height: 1080 px, refresh: 59.940 Hz,
flags: current

The broken Xorg Intel drivers

Without the possibility to properly perform automatic testing in a controlled setup one has to resolve to manual testing. And here things get tricky when the underlying stack is broken. I’m now going to share my experience of the last half year with the Intel Xorg driver for my Ivybridge system. Over the last half year I experienced random breakage whenever I updated the xorg-intel driver. I rebooted my system and something broke. The stack on top did not change – that is Qt and Plasma were the same as on the last (working) usage, but the driver updated. The issues I saw ranged from completely losing one of my outputs to outputs being removed from XRandr when going to DPMS powersaving, incorrect modes, etc. It is quite annoying. And from what users reported I saw that this is a common thing: random breakage in the xorg Intel driver. I have a second system – same distribution, same software stack with Intel Sandybridge instead of Intel Ivybridge and there I never hit those problems. The main issue here – in my opinion – is that Intel stopped releasing the Xorg driver. It hasn’t seen a release for more than two years. Of course distributions need to support something newer, so it happened what had to happen. Basically all distributions are now performing rolling releases from the master branch. Of course that means that broken and untested code gets directly delivered to the users – no blame to distros here. They don’t have much choice. The situation is unfortunate and we cannot really do something about it. Distros have to combine untested code released after our releases. If it breaks, it breaks.

Overall that means that testing is really difficult for us. If you have a problem with your setup it doesn’t mean that any dev has ever run into it. We need your bug reports with very detailed descriptions of your setup to be able to understand what went wrong in your specific case. Then we can fix it. Of course we would like to have this supported better, but without proper ways to test it, it’s tricky. Wayland allows us to test much better in that regard.

QScreen

A big problem for our software is the quality of Qt’s QScreen implementation on X11. This has been a problem since it got introduced. Basically the idea is that a QWindow is attached to a QScreen. On X11 a QScreen is mapped to an XRandR output, which means that a QWindow is mapped to an XRandR output. This is IMHO completely wrong, because an X11 window is positioned on the virtual X11 screen. In addition they changed the behavior and documentation of QWindow::screen to allow null values. After that applications started to crash all over the place. We got the following useful hint in the relevant Qt bug report: “Also, KDE developers should make sure not to 1) assume that QScreen* returned from any Qt function is guaranteed to be non-null 2) hold any QScreen pointers.”

This is a nice suggestion, if our code were crashing. We got crash reports for this constantly (over 50 duplicates just for KWin), just the crash has never been on our side of the world. It always crashed directly in Qt. So to conclude: “Also, Qt developers should make sure not to 1) assume that QScreen* returned from any Qt function is guaranteed to be non-null 2) hold any QScreen pointers.”

This situation continued for a few years with Qt trying to catch up and fix their incorrect assumptions. Unfortunately that is still broken in many distributions. I still constantly get crash reports from users on distributions with Qt 5.5. The situation only improved with Qt 5.6 when Qt finally got the idea to introduce a dummy QScreen when there are no outputs. So on X11 we are back to it’s never null. On Wayland the last time I tried Qt crashed and I concluded that I have to make sure from KWin side that there will always be an output.

With Qt 5.5.1 it also looks like most QScreen related crashers are resolved, but that caused other problems, like a lockscreen bypass. Created thanks to the change in behavior of screen handling between Qt 4 and Qt 5. Up until Qt 5.5.1 it never happened, because the lockscreen would crash and be restarted – that was a situation well handled. It’s an issue I never saw on my own system as I never had Qt 5.5.1.

With Qt 5.6 the situation improved thanks to the dummy QScreen. But that still causes weird issues because the QWindows change their position. Especially in combination with issues like I mentioned above that screens disappear in power saving.

The situation for us and our users is very bad. We are very unhappy with the quality of Qt with regard to QScreen – especially with the random crashers we saw in the past. Of course it doesn’t help to point fingers. We have bugs in our code as well, but it’s difficult to investigate them if your code crashes deep down in Qt when testing the changes. You don’t even see the problems. Thus it happens that we now see new problems appear. Given that the Qt issues are resolved now, we hope to be able to fix those issues in a timely manner. Thanks for understanding and thanks for reporting the issues.

Animations on lock screen – Plasma Wallpaper support

With Plasma 5.7 released I’m allowed to blog about new features in Plasma 5.8. One of the features missed by many users in the Plasma 5 series was the lack of animations in the lock screen architecture. With Plasma 5 we dropped support for the old XScreenSaver and went QtQuick only. Now technically it was always possible to have animations on the lock screen. Our lock screen architecture loads the QtQuick files through the lookandfeel package mechanism, which means that one could provide an animation in a lookandfeel package.

But so far, nobody did that. Which means we don’t have animations on the lock screen. Today I’m happy to announce that this situation is going to change with Plasma 5.8. Our lock screen architecture gained support for Plasma Wallpaper plugins. All the wallpaper plugins available for the desktop are now also available for the lock screen. By default it uses the image wallpaper set to the default wallpaper, but one can also have slide shows, or fancier animations. In fact one could even try to provide a Plasma Wallpaper plugin for the old XScreenSavers.

The support for wallpaper plugins got added as a scratch-your-own-itch solution. For a personal project I must be able to show a slide show on a locked screen and looked at possible solutions for this. Pretty quickly I came to the conclusion that adding Plasma wallpaper support is the best solution and also provides something for all Plasma users. But it also makes me wonder why nobody did that before.

Synchronizing the X11 and Wayland clipboard

One of the greatest annoyances after switching my work systems to Wayland is the lack of clipboard synchronization between the X11 and Wayland windowing system. X11 clipboard is only available to X11 windows and the Wayland clipboard is only available to Wayland windows. It’s the useability problem of the two X11 clipboard (primary and secondary) just exposed on a much higher and more annoying way. Instead of “just” remembering whether you copied or selected text, you need to remember which windowing system you copied from and which windowing system the current window is in. And if they are not in the same, there is just no way.

So getting this problem resolved got quite a priority. It was something I had never really spent any thought on and incorrectly assumed it’s something Xwayland would take care of. But after thinking about the problem I realized that the X11 clipboard is part of ICCCM and not a core feature of the X-Server. It’s a communication protocol between clients.

This means that KWin had to learn to communicate with the X11 clipboard in order to provide the synchronization. Not an easy task as ICCCM is quite complex on this topic and implementing an X11 clipboard is nothing I’m looking forward to. Luckily I remembered that we have a clipboard manager for X11 (klipper) and that this one works without having X11 specific code thanks to Qt’s abstraction.

And this makes the whole thing way easier: by using Qt’s X11 clipboard implementation we only need to interact with Wayland’s clipboard which is thanks to KWayland quite straight forward. The solution involves a small helper binary which gets started by KWin. It’s forced to the xcb windowing system to be able to use Qt’s X11 clipboard and manually connects with KWin through KWayland. The task of the binary is quite simple: whenever the X11 clipboard changes it gets the data and sets it on the Wayland clipboard. Similar whenever the Wayland clipboard changes it gets set on the X11 clipboard.

Unlike the X11 clipboard on Wayland clients are normally not informed about clipboard changes. Only the application currently having keyboard focus gets informed by the Wayland server about what kind of data is available on the clipboard. This means we don’t need to inform all Wayland clients about changes in the X11 clipboard and similar we don’t need to inform X11 about clipboard changes in Wayland all the time. Instead KWin helps the process: when an X11 window gains keyboard focus our helper process gets informed about the current Wayland clipboard content, so that it can be available for the focused X11 window and while X11 windows are focused clipboard changes from the helper application are forwarded to Wayland. So when the next Wayland window gets focused it has the clipboard content set on X11. A small and simple solution which works quite well in practice. At the moment only the “real” clipboard is synchronized. There is not yet the concept of the selection based clipboard on Wayland. A solution might be to just synchronize it to the normal clipboard. But this would again introduce the useability problems of this non-explicit clipboard. So I’m not yet convinced what’s the proper way.

In my last blog post I pointed to our current donation campaign to support the Randa developer sprint. A lot of readers donated after reading this. I want to thank everybody who donated. It’s so important for a free software community to meet in person and we need donations for getting developers to sprints and conferences. Last week I was at openSUSE conference and had a talk about how Wayland improves the quality of Plasma. These are important things to talk about at a conference, but it’s only possible if we have the donations to send people there. Please help to make such developer sprints possible. Thank you!