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.
We have in Gentoo a bug which collects most of the already KDE reported bugs, maybe this helps:
https://bugs.gentoo.org/show_bug.cgi?id=569556#c0
Just adding a comment I also wrote on irc (but I think it’s easier to discover here): it might be possible and helping at least in some cases to set up a VM (e.g. VirtualBox) with multiple monitors and then turn them on/off with “xrandr –output VGA-2 –off”, then “xrandr –output VGA-2 –auto” and even change VGA-2 to VGA-1 (primary). While this is still a lot of manual work, at least it’s something where you can try to reproduce bug reports.
Thanks to everyone looking into this, fortunately I can currently work around my multiscreen issues and am a happy Plasma 5.7 user!
It’s a solution for manual testing, but not for automatic testing – unfortunately. But yes, it helps to simulate a setup.
Just some encouraging words: it’s really great that Plasma 5.7 focused on improving multi-screen support and such posts help a lot to understand the underlying problems. The state here is/was really suboptimal. For instance I downgraded from Kubuntu 16.04 (Plasma 5.5) to 14.10 (Plasma 4.x) again, because my setup (which is different multi-screen configurations at work & home for a notebook with Intel graphics) was unfeasible. It basically meant to reconfigure the Plasma user interface every time when changing location. Unfortunately I didn’t have the time to check with 5.7, but will do in the near future.
I can tell you that for me, 5.7 really did solve the problems I had with my setup, so you have my gratitude for the work you did!!!
Glad to hear!
I just wanted to say thanks for all the work you and every other KDE dev puts into making Plasma/KDE what it is ; excellent. In a world where proprietary OS’s are so locked down that as a visually-impaired user I can’t actually work on them, Plasma has allowed me to work in the way that’s best for me, not dictated by some monolithic un-hearing organisation.
There are countless things, both little and big that I could mention, but the sum of them all is why KDE works! Thanks for making it all happen, now and in the future!
> The broken Xorg Intel drivers
Try modesetting Xorg driver instead.
Yes I know (of course). Unfortunately nothing we can tell users – well we can, but if it’s not the default it doesn’t reach them.
I guess it’s time to ensure that distributions start making the modesetting driver the default, and even stop shipping the intel driver. Ever since I switched to the modesetting driver, my kwin/plasma experience on intel has improved a lot (it’s actually almost flawless now).
Many distributions are already doing that. But yeah maybe ask should switch
isn’t the intel driver using modesetting by default and wasn’t the modesetting driver rather a fallback?
BTW: does Kscreen/Kwin handle dcc events for display port? Since I disabled them and the screen/monitor is still removed from X11. Also I noticed that that both monitors (all connected via DP)
get disabled when one is disabled via powerbutton.
I don’t know what is causing the issue. So I’m asking here first.
The modesetting driver used to be the fallback. But over the last months I have often hard from people more involved in the stack that is the better option nowadays. Pretty much everybody is unhappy with Intel’s release process.
Concerning your other questions: that’s below what we interact with. We don’t listen to such events – only to xrandr events.
modesetting is not a panacea: I tried it because of all the issues in the intel driver with Ivy Bridge but it’s even worse, I got random lockups, crashes, completely broken multiple screen, disappearing text in GTK apps (!!!), etc. In the end I went back to the slightly-less-broken intel driver.
it seems to be GPU dependent. modesetting works pretty good on my Broadwell (i7-5600U) and Haswell G3220, but I’ve seen friends with older cpus having problems.
btw. the modesetting driver uses glamor (for drawing 2d via opengl), and it was removed from the intel driver.
About complaints: well said about testing. Though I don’t understand why even spend so much effort in trying to fix some relique when Wayland should be feature complete very soon. Going back to fix x11 is like what UK is doing: one foot out of the door, by somehow they don’t want to do it. Fix it in Wayland and leave X11 in its place: in history.
Proposal: make new bug reporting app. One currently used is not of use. I had few bugs which i could reproduce, but after few tried to submit them, I had to go to web interface. In other words, from end user perspective, current app doesn’t work.
Personally, I found a few bugs for other products as well (e.g. libreoffice) and I just didn’t feel like opening account online for every app so I can report it.
Like always, good work and interesting read.
> Personally, I found a few bugs for other products as well (e.g. libreoffice) and I just didn’t feel like opening account online for every app so I can report it.
Please, you should make the effort. It is the least you can do as a user. Without an account, bug triagers and developers cannot reach out to you for further information. After creating the account, you should proceed to contribute by triaging other bugs. Then you would be doing something even more valuable than donating money.
That said, the experience of creating an account can be made smoother by using login providers like OAuth (currently KDE’s and LibreOffice’s Bugzilla require a separate account).
I did do it. For KDE and Redhat bugzilla. And then I encountered a few more issues that should be reported on another website. Then i kinda freaked out because of this fragmentation. To be honest, I don’t have time nor the will to do this on overly complicated and fragmented system.
What about contra proposal: let’s point out to OSS community that bug reporting is not working well and the whole process and fragmentation needs to be addressed.
(This has very little with Martin’s post)
Bug reports shouldnt require an account imho. (It could just be a web interface for a mailing list with threads). So you go to the website enter your email address with the bug report, check your email for verifying and you are done. A session cookie to remember your verification so you dont have to verify all the time unless its a new login. 0 hassle, 0 accounts necessary. IMHO that is how the entire internet should work because just like you i got tired of a 100 accounts registered everywhere, gave up on forums and such all together.
Thanks very much for your work!
Could you please briefly describe how kscreen plays a role here? Is it maintained? Should it be used? Does kscreen benefit from those fixes?
Kscreen is well maintained and a very important part of the multi screen story. It’s responsible for setting the screen layout
I’ve almost reported a bug but instead I switched from Intel driver to modesetting and note everything is fine again.
Excellent post, Martin. This is why I read planetkde.org 🙂 Thanks for all your efforts, it is very much appreciated!
Will Wayland support multiple screens with different DPI’s well? My laptop has a HiDPI screen and my external monitor has a regular DPI screen, so interfaces are blown up quite a bit on one.
Yes that will be possible. I think gnome already has support for it
And here is the bug report: https://bugs.kde.org/show_bug.cgi?id=365455
i filled a couple of multiscreen bugs in 2015 with plasma+xorg, they did get replied to with ask for more data (which I provided). each bug has then been left open and ignored with a comment of “i dont think its a kwin issue”
But of course the issues are the ones described in this blog post, and do not happen on xorg+gnome.
All that to say the bug-filled experience has not been great. I’m glad you’re looking at it now though.
To this day I just have a script of xrandr commands so that stuff is setup properly when i connect the new screen.
Sorry that you didn’t have a good buy reporting experience. Sometimes we are not good at it.
I know this is the wrong place to post this, but I had to switch back to Unity until this issue gets resolved. Whenever my laptop is plugged into my external displays and I restart then it only shows the login screen on the laptop which I leave closed. Once I login, then it shows on both screens and I can then logout and back in just fine using the external monitors. On a positive note the monitor configuration in KDE is way better than Unity.
As other KDE users and I reported https://bugs.kde.org/show_bug.cgi?id=356225#c57
In extended mode, the primary screen (left one) works well, but the extended screen (right one) is totally black shown as https://pbs.twimg.com/media/CnIbFaDVMAApqzM.jpg
but it is able to move (for example, chromium) windows to the right https://pbs.twimg.com/media/CnIbGh3VMAAoSZR.jpg
And another tiny issue, the applet Pager became bigger when plugin a new output (monitor) also shown as https://pbs.twimg.com/media/CnIbFaDVMAApqzM.jpg and return normal size after plugout.
I thought Intel periodically produced graphic stack packages for specific distros (https://01.org/linuxgraphics/downloads ). If so it’s a shame that the validation for those didn’t catch the issues intel driver bugs you’ve been seeing. Do you know if bugs exist for the problems you still see?
Well as I wrote: after every restart the problems changed. Including the one from the last run being gone again.
KDE is basically currently unusable for productive use for a large userbase.
This is because the development model is broken. I think this is the biggest bug that should be fixed by the KDE community, otherwise I don’t see a future for this rather cool DE.
I disagree. The development model is not broken. The issues have nothing to do with our development model.
Ok – maybe I am a bit ugly. But you have to understand, I am suffering heavy from the multi-screen woes with KDE – on a computer that worked fine with multi-screen in KDE 4. For me, personally, the “upgrade” to KDE 5 meant a loss in usability.
The bug that affects me most is thisone: https://bugs.kde.org/show_bug.cgi?id=356225
It was opened half a year ago. I cannot use my favorite Lenovo Thinkpad T400 model for presentations in KDE anymore, because of this bug.
Sorry about that. Unfortunately the bug report has quit a bit of noise and buy now probably multiple issues mentioned.
Please show us what is unbroken development model? There is NO bugfree DE about multiscreen relative settings if tested heavily by QA. just fix it or report, thanks a lot!
I’m just assuming here that all of the above mentioned issues are reported bugs. If this is the case than this “just fix it OR report it” mentality is where your development model is broken! It implies a serious lack of manpower to stem such a massive piece of software.
It is better to say MY development model is broken, but please do NOT say the whole KDE devs!
> KDE is basically currently unusable for productive use for a large userbase.
Well – I’m using Kubuntu 16.04 LTS as my productive system on several machines.
Even on my rather old hardware the system is fast and stable – and has a modern
look and feel. Many issues of KDE4 are fixed now and many parts got small, but
very efficient improvements.
After using 14.04 for years KDE5 is a giant leap forward and would recommend anyone
updating older installations.
It’s simply not true that KDE is fundamentally broken and unusable for productive
use.
So, what you are saying is that a minority of users is affected by the bugs above? Is this the case – do you have numbers to verify your claim?
Please answer to what I think are valid points:
1) Why was it released to users without testing? It always take me 20 sec on any KDE fresh install to make it crash very badly, with multi-screen. This is where the development model is broken: how is it possible to realease “stable” software for years when such a basic and essential feature is not working properly? How could you justify that?
2) Ok, the underlying stack is rotten. But why is it working with Gnome? If you haven’t yet, you should test this environment and pick some idea. At least they respected their users in finding a workaround.
First of all: it’s of course tested. If it crashes that badly for you, you are running into issues which we don’t hit. That happens and is exactly the reason why I ask for bug reports.
Concerning why it works on GNOME: quite simple, they are built on top of GTK+ and didn’t face the QScreen breakage. Other issues with the underlying stack are of course also hitting GNOME. Sometimes in less, sometimes in more degree.
Hi phocean, you can touch $HOME/gsd-debug-randr, then logout/login to GNOME, gnome-settings-daemon will generate gsd-debug-randr.log, and do some heavy test for GNOME’s MultiScreen behavoir:
1. press XF86Display hotkey several times to switch between Primary, Secondary Display, Mirror and Turn Off modes, does everthing behavior normally? gnomeshell correctly moves to Primary screen or not?
2. plugin/plugout outputs several times, much clear if there are more than TWO monitors, is it able to “remember” the configuration? WITHOUT switching from extended to clone mode randomly?
I experienced 3 monitors heavy test for GNOME, my customer did that in front of me, when plugin/plugout randomly several times, it is NOT able to “remember” the configuration (including shell’s position) correctly!
So there is NO bugfree DE at all, please fix it if understood the DRM architecture and know how to use it and modify if necessary just like Qt’s JD https://www.qt.io/embedded-graphics-engineer-oulu/ saying “development model is broken” is helpless!
Regards,
Leslie Zhai
Have you opened bugs for Matlab and Skype? Often big companies ignore such issues, especially if they are fixed by KWin already. But sometimes they pick improvements up and no more work-around will be necessary.
Regarding beta testing: As being a open source developer myself, I can feel your pain. I have to confess that I didn’t test any pre-release version of any part of KDE 5. Not that I am not interested, but I lack the resources. I am already testing GCC, Clang and CMake release candidates, similar for a bunch of other software I use.
Thanks for your hard and often non-rewarding work.
No I haven’t, because I have no idea where to report such issues. You know a bug tracker for skype? I don’t. Matlab I don’t even have on my system.
In 2012 there was a Jira for Skype, but that is gone for several years. For Matlab you need an account. *sigh* I love the open source world.
http://www.phoronix.com/scan.php?page=news_item&px=Skype-New-WebRTC-Client
Skype released a new client based on Chromium, so one problem solved. The more important on Matlab still on the table!
It seems Microsoft will start over with Skype for Linux. And they want feedback from the community. Let’s see how this pans out.
https://community.skype.com/t5/Linux/Skype-for-Linux-Alpha-and-calling-on-Chrome-amp-Chromebooks/td-p/4434299
>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.
Beta testing is never a simple task, and in particular when a (screen) configuration has to be stored after logoff a temporary solution or life image is not sufficient. But please correct me (at best in another posting) if I’m wrong.
About the rest: Thanks for making this clear.
But indeed, a live image with an overlay for configuration (on a USB stick) would help.
So which live image can you recommend?
I don’t think there’s a big difference between them. Any one should do
about “Please report your bugs”:
I reported two bugs (364709) and (364710) on the beta – one of them (364709) being a showstopper IMHO. Nevertheless kwin got released although none of these bugs got fixed.
I also reported one or two kdepim bugs – same story there.
Don’t get me wrong. I really appreciate the work you guys are doing and I really like plasma/kde 5. But if you *do* get the bug reports, and still release without fixing the bugs, I can understand why users get disappointed.
Thanks for reporting those bugs and sorry that I didn’t get to investigate them properly. You reported them while I was at openSUSE conference. Thus they just did not get the attention by me which they should have.
Investigating the desktop grid issue is pretty high on my todo list. But I also have other issues to investigate.
It appears that one way to fix this might be to donate a second monitor to a bunch of Qt developers, so they can see the problems themselves. (I’m a little surprised they don’t already have one. Maybe they’re all single-screen laptop users.)
Have you read the post at all? Despite they are using multi-screen setup, depending on the distribution, Qt version, graphic hardware and so on they encounter only a fraction of problems themselves.
My ideal multi-screen configuration is a “Presentation” one – ie I almost never use typical multi-screen foe work.
In that scenario, the external screen should not have any application unless I explicitely put it there – especially not pop-ups from my chat apps :).
Also, the external screen shoudn’t have virtual-desktops
Well, Intel guys even know the issues, and my best guess is that they won’t release until the atomic stuff is done.
Quote from Daniel Vetter, (3/2/15), intel-gfx mailing list:
“But switching to atomic amounts to a full rewrite of the drm core and
drivers (semantics for modeset updates are totally different). So there’s
lots of glue and ducttape going on to keep up the illusion for both old
code and partially transitioned driver. It’s all a bit wobbly atm and
don’t loook too closely at some of the hacks we have.”
This is not about the drm driver, but about the xorg driver.
Hi Martin,
I am a developer at The Mathworks Inc. Could you let me know the version of MATLAB used in your testing. http://www.mathworks.com/help/matlab/ref/version.html
The window type is set to _NET_WM_WINDOW_TYPE_SPLASH for MATLAB’s splash window since R2014b (about 5 releases now) so I wonder if you are using an older version.
Thanks,
Abhinay.
Sorry, but I don’t know. I only got the output from another developer. I myself don’t have MATLAB.
I’m the one who reported it. I’m using Matlab 2015b…. Linux version
8.6.0.267246 (R2015b)
I was using Matlab r 2016a i think when I reported this bug involving the positioning of matlab splash screen.
Seems a problem similar to the one in the post.
https://bugs.kde.org/show_bug.cgi?id=361953
For the xprop output of the one attached window it shows a requested position. Same problem as mentioned in but report. Please also add xprop output for the other affected windows. I’m trying to find a pattern to better handle these cases
Thanks for this article and for the explanation.
What I would recommend is that you provide a link where to report bugs (at least in the “Please report your bugs” section) so that people who read this know exactly where they should report bugs. I know they should be reported on https://bugs.kde.org/, and it’s obvious to you, but that might not be the case for everyone. You should make it as easy as possible to report bugs, and maybe even make it possible to report bugs directly from KDE, e.g. by providing your email (so the devs can contact you), or being able to login into a bug reporting app, or even give a link in KDE where to report them.
Regarding QT bugs, is there something we the users can do about it? Can we vote on the bugs or something, so that those issues get more traction?
Also I’ve been a KDE5 multi screen user since Kubuntu included it, but it’s usually “set it up and don’t unplug anything” (this mostly works). I tried 5.7 from the Neon live image and I found that it works a lot better, but I also found some bugs with one screen background going black, which will I report tomorrow.
Thanks for the feedback: you’re absolutely right, I totally forgot to add the link to bugs.kde.org. Did not think about it at all.
Concerning Qt bugs: difficult. Qt normally doesn’t get bug reports from users and even we as quite close collaborators are in my opinion mostly ignored. I don’t see what can be done about it from user side.
Concerning the black screen: I think that’s already known. But bugzilla should show some possible candidates.
“KWin places new windows on the “active screen”.”
I desire the windows be placed how I last put them. It is important to me that they don’t move even if I turn off a monitor. A solution for those that lose windows outside of visible area, is for a desktop menu item to bring windows into the active screen, with options like cascade-all-windows.
Thanks for asking this comment. Quite important to remember that there are different workflows and that changing the current behavior would break yours
This solution would be great.
My work flow.
Notebook at work with 3 monitors and many windows open. When I go home (single monitor) I would like to be able to resume the notebook without altering the windows position, so that I can switch activity and work on a single monitor, and when I go back to work find all the windows where I left them on the work activity.
Maybe having something that allow to select a specific window a bring it back from the unreachable are would be even better.
That exists: right click the task manager entry, select more actions, move
Thanks for the great explanation!
Could I suggest future release announcements use wording like “KDE Plasma 5.8 for QT 5.8”, as opposed to maybe listing QT version requirements in some requirements section/text.
I say this after reading the first few pages of comments to an article on another site* linking this blog post. (*think green Ph).
There is an implicit expectation that a particular version of “KDE” will run as long as all the correct “KDE” libraries are there. QT might be seen as a sort of “system library”, that should be left alone.
Plasma sets a dependency on the Qt version it needs. In the end that’s a technical detail only relevant for distributions
First of all thank you for your work on multi monitor support for Plasma.
I am leaving a comment on your blog because I wouldn’t know how to open and describe a bug report since the issues I am experiencing are so random that they are practically impossible to describe in my opinion.
-Desktops (more precisely the taskbar) are switching places on every restart
-Taskbar moving to the monitor just disconnected
-Laptop monitor stays black and “deactivated” with no way of changing the situation
What I experienced in comparison with GNOME:
-none of the above issues happen
-same hardware setup
-GNOME using X.org
Hints for Plasma:
-Display placement issues “mostly” resolved with Wayland but since Wayland is completely unusable for me this is not a solution
Hello Martin,
Maybe I can provide you some solutions:
Regarding invalid hints from applications: The worse situations are when window is positioned outside visible area. You can mitigate that by detecting some obvious invalid situations, eg. when window trying to place himself outside visible screen, and in that case you ignore all hints because you are sure that this application is misbehaving.
Of course you should also log somewhere what application done, and why you ignoring its hints, so developers would know that they application doing something wrong.
For the situations like you have with skype, you can create workaround repository where you can enable/disable kwin scripts that fixes applications behavior.
Regarding testing situation:
You already implemented abstraction part for display system, you have code that is independent from X11 or Wayland, IMO you should implement third system: MockDisplay.
You probably don’t expect many issues in platform dependent part and it probably isn’t that much functionality that you cannot test in dogfooding process.
When you have mockuped system, you can also check if some action are called exact times, and check if you are calling them in right way instead of only checking effects of those.
For intel driver issues or other known problems you should create some workaround subsystem, that allow you to change some behavior only when you detect specific driver, this solution is used for example in chromium. In some very misbehaving driver like intel, you should pop up an notification with tell user that this driver isn’t supported and have known problems etc, and you should switch to modesettig driver for never hardware. (btw. it working better that intel driver on skylake)
To know what issues are critical for user, you should implement telemetry system and measure what features and what configuration your users have, so you can know on what problems you should focus and whether your solutions are working.
I looking forward for further discussion.
Best Regards
Piotr
There are valid situations to place windows outside the visible area. KWin does so.
The window is override-redirect. Even KWin scripts won’t work for them. They explicitly disable window management on them. No dice from our side on X11.
If there is an obvious simple solution it means that this solution won’t help. We have this MockDisplay thingy, it’s called “Wayland”. The problem is with XRandR. We cannot mock it and it wouldn’t help. We don’t care whether our code is correct to our XRandR mock, it needs to be correct to the real XRandR – and that we just cannot simulate.
This is outside of our control. Plasma cannot influence the xorg driver being used. Also we cannot detect which xorg driver is being used. AFAIK there is no way to detect that or apply workarounds for that. You can do such things on OpenGL level – and we do that. But this is the xorg layer.
This is certainly something which would be useful, but also violates some of the core values of our very privacy aware community.
Hello Martin
> There are valid situations to place windows outside the visible area. KWin does so.
Can you expand this topic? Maybe we can detect those few situations.
>The window is override-redirect. Even KWin scripts won’t work for them. They explicitly disable window management on them. No dice from our side on X11.
Ok, for this particular situation, but for many other it will work. Don’t even try to cover all cases, it is good enough to cover most of them.
>We don’t care whether our code is correct to our XRandR mock, it needs to be correct to the real XRandR – and that we just cannot simulate.
So, bugs aren’t in plasma code but in the XRandR code?
How this is solved in other WM? Gnome seams don’t have that problems.
Also maybe you could request required features to xorg guys? Maybe they can implement some way to simulate that.
Also I think many issues are caused by plasma code so, they should be caught by existing mockup, right?
>This is outside of our control. Plasma cannot influence the xorg driver being used. Also we cannot detect which xorg driver is being used. AFAIK there is no way to detect that or apply workarounds for that. You can do such things on OpenGL level – and we do that. But this is the xorg layer.
Chromium can do that, but Plasma can’t? look at chrome://gpu in chrome, you can detect GL_VENDOR and react on that.
> This is certainly something which would be useful, but also violates some of the core values of our very privacy aware community.
Make it opt-in feature, just ask users if they want to provide developers anonymous statistics about how they use Plasma and what problems, errors occurred.
Just make sure this won’t expose any private information.
Mozilla also is privacy focused company, and they have telemetry system in Firefox.
If user have to opt-in to this and he know what information he expose, it is ok for me.
You could make great use with statistics, like how many crashes are in what component on what distribution, instead of relying on bug reports that aren’t user friendly.
Best Regards
Piotr
The idea is to keep windows around, but not show them. How should one know that this is the case?
Issues are mostly in the interaction with XRandR code, yes. That is either our code interacting with XRandR or code interacting with XRandR through QScreen. That GNOME doesn’t hit these problems is pretty much irrelevant, I haven’t heard that they ported to Qt 5. Most of our multi-screen issues are caused due to the port to Qt 5 and the problems we had with them. There are many issues we only start to see now after Qt stopped to crash when you change screens.
I mentioned the lack of XRandR support in Xvfb in my talk at XDC 2014. So yes, we did.
That’s the OpenGL layer, not the xorg layer. It doesn’t tell us whether you are using the intel xorg driver or the modesetting driver, etc. That’s exactly what I said in the comment before. We have detection code for the OpenGL driver after all…
isn’t is using something like negative position to make sure?
I through that KDE people and Qt people are collaborating much better.
Maybe you should to improve relations with them? And face that issues together?
But is there any bug report or something?
I said many times in many places problems I have with plasma, and no one fixed them.
Cannot it be detected by some specific behavior? Maybe there is an easy to detect issue that is specific only to inter driver? (I know, it’s some kind of hack)
Or you could show an message in eg. compositor settings about best driver always when you detect new intel hardware (this info in in GL layer), It will be also visible for people already using modesetting, but right now we have many people that aren’t aware of that alternative (including me few days ago)
I mirror my screen to my second display (a TV), so if I want to play a game on the sofa, I’ll just turn on my second screen.
This generally works great, there’s no windowing issues as it’s almost just like a single display, but even so, there’s a bit of a quirk. I still have 2 ‘desktops’. If I alt-tab, I can switch between these desktops, and my wallpaper and plasmoid configuration changes.
I’d be very interested if there’s a workaround, or if I’ve configured something wrong.
More details here: https://forum.kde.org/viewtopic.php?f=111&t=133813
Hello Martin,
>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.
well, I realize that the X11 is no more a first-class citizen and the support for it is most probably not worth the effort – but still, if you dislike the XCB platform plugin that much, why don’t you make a better one? You already did it once for Wayland.
I never did a replacement plugin for Wayland. I did a very limited plugin for kwin’s need but not a general one.
Thank you for this post. It is really interesting to know where these effects have their origin, I observed many of the, too.
Looking forward to the wayland times …
Hi All KDE users and devs,
Please do Heavy testcase for Plasma MultiScreen https://forum.isoft-linux.org/viewtopic.php?f=4&t=32&p=137#p137
BUG list:
* KDEBUG-356225 https://bugs.kde.org/show_bug.cgi?id=356225
* KDEBUG-354823 https://bugs.kde.org/show_bug.cgi?id=354823
* KDEBUG-365455 https://bugs.kde.org/show_bug.cgi?id=365455
* KDEBUG-351399 https://bugs.kde.org/show_bug.cgi?id=351399
* KDEBUG-362531 https://bugs.kde.org/show_bug.cgi?id=362531
* Primary screen randomly switch to DesktopView, extended is not DesktopView by default
Testcase list:
* press Display or Meta + P several times to switch between Clone, ExtendToLeft, TurnOffEmbedded, TurnOffExternal and ExtendToRight modes
* plugin and plugout (more than TWO outputs is better!) several times
For better KDE, better Plasma,
Leslie Zhai – a KDE developer https://git.reviewboard.kde.org/users/lesliezhai/
I just comment to express my appreciation to your work on this DE. Thank you all very much for this wonderful Plasma 5.7 although some glitches do still exist.
I appreciate the time and effort you all are putting in. I have been struggling with switching between a tri-monitor session at work, a single laptop screen in the commute, and a dual-monitor situation at home. In the worst cases the task bar disappears for days, or that I get a 1cm strip on the top of my laptop screen in all configurations. The setup can go weeks where it works perfectly only to break again. So I’m not sure your live image solution would prove anything.
I have needed to switch back to lxqt for days as there is no way to fix these issues. FYI lxqt have two tools to do screen management. One is advanced and is similar to “Display and Monitor”, but the other is a basic “turn on/off” that always works.
Now I know how to and where to log bugs, I will. But knowing that there are so many issues with multi monitor, it would be good to move from the “assume it’s ok” approach to something where there is fall back and recovery. I would recommend that you (re)implement falling back to the old settings if no confirmation button is clicked. This need not be enabled by default, but there as an option if you’re unlucky enough to have issues. You should also consider implementing a fail safe mode, or provide some way to flush the existing settings from the console.
Dolphin menu opens on wrong monitor
http://imgur.com/a/YbnyQ