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.
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.
