Multiscreen in Plasma 5.7 and beyond

Here’s a quick status update about where we currently stand with respect to multiscreen support in Plasma Desktop.

While for many people, multiscreen support in Plasma works nicely, for some of our users, it doesn’t. There are problems with restoring previously set up configurations, and around the primary display mechanism. We’re really unhappy about that, and we’re working on fixing it for all of our users. These kinds of bugs are the stuff nightmares are made of, so there’s not a silver bullet to fix everything of it, once and for all right away. Multiscreen support requires many different components to play in tune with each other, and they’re usually divided into separate processes communicating via different channels with each other. There’s X11 involved, XCB, Qt, libkscreen and of course the Plasma shell. I can easily at least three different protocols in this game, Wayland being a fourth (but likely not used at the same time as X11). There’s quite some complexity involved, and the individual components involved are actually doing their jobs quite well and have their specific purposes. Let me give an overview.

Multiscreen components

Plasma Shell renders the desktop, places panels, etc., When a new screen is connected, it checks whether it has an existing configuration (wallpaper, widgets, panels etc.) and extends the desktop. Plasma shell gets its information from QScreen now (more on that later on!)

KWin is the compositor and window manager. KWin/X11 interacts with X11 and is responsible for window management, movement, etc.. Under Wayland, it will also take the job of the graphical and display server work that X11 currently does, though mostly through Wayland and *GL APIs.

KScreen kded is a little daemon (actually a plugin) that keeps track of connected monitors and applies existing configs when they change

KScreen is a module in systemsettings that allows to set up the display hardware, positioning, resolution, etc.

Libkscreen is the library that backs the KScreen configuration. It offers an API abstraction over XRandR and Wayland. libkscreen sits pretty much at the heart of proper multiscreen support when it comes to configuring manually and loading the configuration.

Primary Desktop

The primary display mechanism is a bit of API (rooted in X11) to mark a display as primary. This is used to place the Panel in Plasma, and for example to show the login manager window on the correct monitor.

Libkscreen and Qt’s native QScreen are two different mechanism to reflect screen information. QScreen is mainly used for querying info (and is of course used throughout QtGui to place windows, get information about resolution and DPI, etc.). Libkscreen has all this information as well, but also some more, such as write support. Libkscreen’s backends get this information directly from Xorg, not going through Qt’s QScreen API. For plasmashell, we ended up needing both, since it was not possible to find the primary display using Qt’s API. This causes quite some problems since X11 is async by its nature, so essentially we ended up having “unfixable” race conditions, also in plasmashell. These are likely the root cause of the bug you’re seeing here.

This API has been added in Qt 5.6 (among a few other fixes) by Aleix Pol, one of our devs in the screen management team. We have removed libkscreen from plasmashell today and replaced it with “pure QScreen” code, since all the API we need for plasmashell is now available in the Qt we depend on.

These changes should fix much of the panel placement grief that bug 356225 causes. It does need some good testing, now it’s merged. Therefore, we’d like to see as many people, especially those reporting problem with multiscreen, to test against latest Plasma git master (or the upcoming Plasma 5.7 Beta, which is slated for release on June, 16th).

Remember the config

Another rough area that is under observation right now is remembering and picking the right configuration from a previous setup, for example when you return to your docking station which has another display connected. Bug 358011 is an example for that. Here, we get “spurious” events about hardware changes from X11, and I’m unsure where they come from. The problem is that it’s not easy to reproduce, it only happens for certain setups. This bug was likely introduced with the move to Qt 5 and Frameworks, it’s a regression compared to Plasma 4.
I’ve re-reviewed the existing code, added more autotests and made the code more robust in some places that seemed relevant, but I can’t say that we’ve found a sure solution to these problems. The code is now also better instrumented for debugging the areas at play here. Now we need some more testing of the upcoming beta. This is certainly not unfixable, but needs feedback from testing so we can apply further fixes if needed.

Code quality musings

From a software engineering point of view, we’re facing some annoying problems. It took us a long time to get upstream QScreen code to be robust and featureful enough to draw the lines between the components involved, especially QScreen and libkscreen more clearly, which certainly helps to reduce hard-to-debug race conditions involving hardware events. The fact that it’s almost impossible to properly unit test large parts of the stack (X11 and hardware events are especially difficult in that regard) means that it’s hard to control the quality. On the other hand, we’re lacking testers, especially those that face said problems and are able to test the latest versions of Qt and Plasma.
QA processes is something we spent some serious work on, on the one hand, our review processes for new code and changes to current code are a lot stricter, so we catch more problems and potential side-effects before code gets merged. For new code, especially the Wayland support, our QA story also looks a lot better. We’re aiming for near-100% autotest coverage, and in many cases, the autotests are a lot more demanding than the real world use cases. Still, it’s a lot of new code that needs some real world exposure, which we hope to get more of when users test Plasma 5.7 using Wayland.

28 thoughts on “Multiscreen in Plasma 5.7 and beyond

  1. Great move. Multi-monitor support is really in need of attention. The biggest gripes I have is window/plasma positions changing when a monitor is turned off and later turn on again, and sometimes KDE fails to detect the resolutions or other settings and you get this cycle of screen resetting or you have to manually set the monitor values again. I wasn’t sure if one of my old monitors was failing as you’d hear a buzzing when it tried locking onto a resolution/frequency. Possibly KDE was failing to set the correct refresh rates.

    I was also thinking that maybe the direction to support tablets/phones was setting a policy to force desktop layouts to suit screen changes, rather than respect the User’s positions of windows/dialogues etc, and then allow an option to bring windows into view if they are outside, manually. It’s really important to respect the User’s choices.

    1. There should be some improvement in those areas, but it sounds like you’re running into multiple problems that effect each other. We’re trying to fix those things one by one, and having each of them fixed, the next one becomes a little clearer.

      1. Possibly as both monitors reset and attempt to recheck when one is turned on while another is already on. It’s strange as if a monitor is happy no chances should happen to it. Only adjust/detect the new monitor coming into play.

  2. Good to see multimon problems are acknowledged and a priority, thanks.

    For myself, not a huge issue with my static dual monitor setup, basic plasma boots up in the right layout reliably.

    However desktop widgets migrate all over the place, they are never in their original positions on startup. I put it down to screens being resized and flipped around on init before being finalised.

    1. I have a fix for a race condition during init in the pipeline, let’s see if that changes the situation. Also, the patches Aleix merged yesterday are closely related. I expect an improvement in that area.

  3. Does that mean that multi-monitor setups will also work under Wayland in 5.7?

    1. Depends. We have some bits basically working, but it’s not complete as of now.

      In Wayland, current master should at least be able to set the positions of displays, which is arguably the most important bit. I don’t think we can get it complete and stable in time for 5.7, but let’s see how the coming two weeks (until freeze pan out). I have to make some calls prioritizing some bits over others, and I think making screen management under X11 more robust is also very important.

  4. Thanks for the work you put into those issues and thanks for the writeup. Will test, once 5.7 Beta becomes available in fedora.

  5. A big thanks to you!

    everytime i had to give a talk i held my breath when i plugged in the projector because in 50% of all cases that would render my plasma session unusable. In some occasions not even rebooting helped and i had to wipe my dotfiles from a tty.

    BUT

    Since the upgrade to qt 5.6 (and plasma 5.6) everything works like a breeze! The screen does not even flicker when i plug in the hdmi cable and plasma just silently adds the new screen without any hickups. Its amazing how far multiscreen has come during the last six months. Keep on the good work!

  6. I’ve just installed the newest packages for OpenSUSE Tumbleweed from Factory
    kscreen5: 5.6.90 (git 2016-05-10)
    libkscreen: 1.0.5-2.2
    libkscreen1: 1.0.5-2.2
    libkscreen2-plugin: 5.6.90 (git 2016-05-06)

    inside a VM (VirtualBox) with two monitors, set to “side-by-side”. If I do “xrandr –output VGA-2 –off” and “xrandr –output VGA-2 –auto” I end up with duplicate desktops. If I use the KCM to put them side-to-side again, the panels are now placed correctly (which is an improvement over the previous versions!) I also have to hit “Apply” twice in the KCM.

    Would you like a followup on one of the bug-reports in BKO? Do you need any more information? Are my versions even new enough?

    1. Not new enough, unfortunately. We only merged some relevant bits yesterday, so it has to be new as of today, pretty much.

      Thanks for taking the time to look into it, though! Let me know once you can acquire or build unstable versions and test them!

      1. I’ve now updated all packages (OpenSUSE Tumbleweed with Factory repositories):

        kscreen5: 5.6.90git~20160601T170146
        libkscreen2-plugin: 5.6.90git~20160602T103902

        Unfortunately, the issue remains, even after clearing “.local/share/kscreen”: if I disable and re-enable the second monitor, I have a “clone” of my desktop, while it was side-by-side before.

        Please let me know if
        – I should ammend an existing bug with information from kscreen-console (which info?)
        – I should open a new bug (any special keywords?)
        – you would like to get the virtualbox-disc (6.4 GB)

        Feel free to contact my by e-mail if you’d like to & again: thanks for your work!

  7. Oh, I forgot: thanks so much for working on this, it is my last “big” annoyance of Plasma 5 :-) And it’s not even that big as I just leave my monitors powered on all the time (i.e. not using the hardware button to really, really turn them off)

  8. Since you mentioned docking stations: can you give me a hint which components are involved when I wakeup my laptop on the docking station, to make it enable the external video display, instead the internal, and how to debug those (with OpenSUSE Leap (i.e. new kernel, new driver, new X11, new kwin, new Plasma) the external display is not activated anymore) ?

    Thanks
    Alex

    1. This is handled by the KScreen daemon. It has a handler for Device::resumingFromSuspend(), which triggers re-reading the configuration. The code is in kscreen/kded/daemon.cpp, around line 120 in master.

      To get at the debug output (which should give you a good idea of what’s happening), kill (or kquitapp) kded5 and restart it from a console. Make sure that your qtlogging.ini contains kscreen.*=true as kscreen and libkscreen use categorized logging.

      What it should do is roughly:
      – receive a configChanged signal, post-resume
      – check if something relevant changed
      – run the KScreenDaemon::applyConfig codepaths

      I’d be very interested in your findings.

  9. Hi Sebastian,

    first of all, thank you for the huge amount of work you people put in, it really improved much in recent days.
    I have Request #125451 patched on top of 5.6.4 and it indeed helped for one of my laptops inside a docking station. The other laptop still cannot handle docking. However, it survives all combination of monitors i connect to it via VGA and displayport – which is far better than before. Sometimes there is still a hiccup with plasmashell, where it thinks its on another screen (wrong background etc.).

    Finally, I would ask you people for a proper guide on how to provide debug outputs. I see that systemd grabs most messages somehow and I’m not sure where to enable all the log output messages. Do you have such a guide?

    Best,
    Matthias

    1. In order to get debugging output, first enable the logging for kscreen in your qtlogging.ini, add a line like the second (add the rules section if the file is empty as first line):

      [Rules]
      kscreen.*=true

      Then, to see what’s going on at runtime, kquitapp kded5 and restart it using “kded5” on a console. You can read the debug output in a terminal now, or redirect it to a file.

      Likewise, you can start kcmshell kscreen in a terminal and get debugging output.

      I’ve recently added a small tool called “kscreen-doctor” which gives some information about the system that are useful for debugging.

      Thanks for your help!

  10. A related issue is high dpi support for multiple monitors with different resolutions. Currently kscreen can only configure one scale factor for all monitors. And the scale factor is somehow not applied on startup, so plasma always starts up with the wrong scale factor and I have to quit and restart all relevant applications.

    Basically one should be able to configure a different scale factor per monitor and
    – applications should support multiple scale factors (one per monitor)
    – windows should dynamically scale when moving a window from one monitor to another

    Thanks a lot for your work!

  11. Hello Sebas,

    there is also this annoying bug https://bugs.kde.org/show_bug.cgi?id=346535 which seems to be unaffected by the new patch. Any proper way to find what the bug is caused by (kscreen/xorg or drivers) and add the guide to the bug report so users can provide some useful debug information?

    Thanks for all the great work!

  12. Hi,

    I have encountered a bug with this patch :

    https://git.reviewboard.kde.org/r/125451/

    I have a dual monitor setup and my Plasma panel is on the laptop screen at the bottom). With the patched version of plasma-workspace, if I put a window fullscreen on the laptop screen, the bottom of the window goes behind the panel. I checked the panel configuration and it’s “Always visible”, so it shouldn’t do that. reverting to the unpatched version (official Archlinux plasma-workspace package) fix the problem.

    I thought you might want to know.

  13. Nice. However, what’s the status of Plasma crashing every time the monitor (single!) is turned off? It was touted tat Qt 5.6 will fix it, but it did not fix it at all. Still a crash in KScreen somewhere. It’s been filed as bug 340267 and has been around for 1.5 years already.

  14. Thanks!! That’s very very good news. And it means I’ll likely be a lot less hesitant to encourage my co-workers to use KDE in the future.

    I’ve just donated to KDE to celebrate :)

  15. I’m glad you’re working on this. I realize that my setup, multiple monitors with ATI graphics, may not be the most common. All of the different possible configurations are difficult to account for. I have a Saphire Radeon HD 7770 driving two identical 1920×1080 monitors. Leap 42.1 with KDE and Plasma with AMD driver crashed in just two days. Upgrading to Tumbleweed with the latest doesn’t let me use Dual Head or Extended Desktop or the AMD driver. From the posts I’ve viewed upgrading to a GeForce video card doesn’t sound like that works either.

    Given that Leap 42.1 KDE/Plasma with dual monitors crashed within two days, and the latest Tumbleweed with KDE/Plasma does not support extending the desktop across two displays, nor the ATI driver, and KDE/Plasma requires KDE, Plasma, ATI, X11, Qt, and who knows what; I think I’ll try a different desktop. I don’t see how KDE/Plasma will ever work for more than a single update cycle. Unless all of the pieces are backwards compatible and stable at least for a year or two. Then upgrading one won’t beak another. I suppose you also then need to be able to specify different levels or combinations of dependencies. If that doesn’t exist the system won’t let us update individual pieces.

    Sounds like a difficult problem and we wish you luck. I’ll move on to another desktop and reevaluate KDE/Plasma the next time I need to upgrade.

  16. This looks really promising. I’ve been using your KScreen-removal patch (backported to 5.6.4) for weeks on two systems of mine without trouble. Prior to that, on my single-screen systems, Plasma had begun to crash on display suspend/switchoff (every time) after I had switched to DisplayPort cables (no issues with DVI).

Comments are closed.