SUMMARY My Linux desktop has 6 monitors (connected to two Nvidia 750Ti GPUs). This is across two xscreens. The first GPU is for xscreen0 which has 4 monitors, the second GPU is for xscreen1 which has 2 monitors. I run KDE and plasma on the first screen only, and the second xscreen I don't run a desktop environment (instead I use compiz for display). This configuration has worked well up to plasma version 5.23.5. After upgrading to 5.24.4 (and also 5.24.5) Plasma is starting on xscreen1, and two of the xscreen0 monitors don't have Plasma running (there's no context menu, no wallpaper). STEPS TO REPRODUCE Run plasma in a environment with more than one xscreen. OBSERVED RESULT Plasma tries to run on both xscreens but only runs on as many monitors in total as there are on the first xscreen. EXPECTED RESULT Either: Plasma should only run on xscreen0 (as it used to) OR Plasma should run fully on both xscreens OR There should be configuration somewhere to control which xscreen it runs on. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Gentoo 5.15.41 (available in About System) KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION
I suspect this may be related to how [ScreenConnectors] work. In my .config/plasmashellrc file I have this: [ScreenConnectors] 0=DVI-I-1 1=HDMI-1 2=DVI-D-0 3=HDMI-0 When running "xrandr --listmonitors" on xcreen0 it returns: Monitors: 4 0: +*DVI-I-1 1920/598x1080/336+1920+1080 DVI-I-1 1: +HDMI-0 1680/473x1050/296+240+30 HDMI-0 2: +DVI-D-0 1920/521x1080/293+1920+0 DVI-D-0 3: +HDMI-1 1920/480x1080/270+0+1080 HDMI-1 When running it on xscreen1 it returns: Monitors: 2 0: +DVI-I-1 1680/433x1050/271+0+0 DVI-I-1 1: +DVI-D-0 1920/509x1080/286+0+1050 DVI-D-0 Notice that both xscreen0 and xscreen1 have a monitor with the same name (e.g. "DVI-I-1"). My current hypothesis is that this fact is confusing the startup of the plasma shells.
I wonder if this is related to one of these issues: https://bugreports.qt.io/browse/QTBUG-101203 https://codereview.qt-project.org/c/qt/qtbase/+/412385
Could this be due to this code in ScreenPool::load // Populate allthe screen based on what's connected at startup for (QScreen *screen : qGuiApp->screens()) { // On some devices QGuiApp::screenAdded is always emitted for some screens at startup so at this point that screen would already be managed if (!m_allSortedScreens.contains(screen)) { handleScreenAdded(screen); } else if (!m_idForConnector.contains(screen->name())) { insertScreenMapping(firstAvailableId(), screen->name()); } } This is matching screens based on the name of the screen. It looks like the QT structure at QGuiApplication::screens contains all screens from both of my xscreens (xscreen0 and xscreen1) when it used to only provide those from xscreen0. Matching by name won't work as these aren't unique. I'll check previous versions of ScreenPool to try and isolate the regression to that class (and hence Plasma) before looking at QT.
I have identified that this issue is caused by the change between 5.23 and 5.24 in screenpool.cpp ScreenPool::load. I have fixed this with a patch which allows me to blacklist monitors from Plasma by their serial number. Unfortunately QScreen doesn't expose the xscreen that the monitor is on (eg. :0.0 or :0.1) which means that it's not easy to stop shells from running on a monitor for a particular xscreen. The only unique identifier for screens is their serial number. With my patch you can add a section like this to the plasmarc: [IgnoreScreens] 0=G455H97ABNCL- 1=D59H25C8BJ3S- And Plasma shell won't start on those displays. This fixes the bug for me and reverts Plasma workspace back to the previous behaviour. The patch file is attached. I think a proper fix it to limit Plasma (or QT) to one xscreen. Even with "DISPLAY=":0.1" or --display=":0.0" set when running plasmashell it's still picking up monitors from ":0.1". This is a bug, it shouldn't be looking at displays that aren't the DISPLAY variable. Another fix it to change QScreen to expose the xscreen number which would then allow plasmashell to decide which screens it can and can't run on.
Created attachment 150133 [details] Allows monitors to be blacklisted from Plasma by their serial number This allows us to tell the Plasma Shell to not run on particular monitors by their serial number. The blacklist of monitors is set in plasmashellrc. Serial number is used as it's the only unique way of identifying a monitor.
Comment on attachment 150133 [details] Allows monitors to be blacklisted from Plasma by their serial number Note: this patch is from a gentoo system and is made for plasma-workspace-5.24-5.
Please create an MR over at https://invent.kde.org/plasma/plasma-workspace instead of attaching here, it will get much more attention.
(In reply to Andreas Sturmlechner from comment #7) > Please create an MR over at https://invent.kde.org/plasma/plasma-workspace > instead of attaching here, it will get much more attention. Thanks. My patch fixes my individual problem but it's not necessarily the best solution. I think that QT/Plasma should be ignoring monitors that aren't on the current xscreen. My patch allows us to blacklist monitors by serial number. Should Plasma only run on screen0? It would be great if it ran on all xscreens, but that we should have a choice through config. I think the [ScreenConnectors] config should be changed from this format: [ScreenConnectors] 0=DVI-I-1 1=HDMI-1 To this: [ScreenConnectors] 0=0:DVI-I-1 1=0:HDMI-1 Where the "0:" is the screen number. This way we can run Plasma on only one xscreen, or on both even when monitors have the same name.
Sorry you didn't get more responses sooner. Mose of the code here has changed to improve multimonitor use-cases in Plasma 5.27, so the original issue may no longer be possible. Can you reproduce the issue in Plasma 5.27.4? If you can, can you reproduce it on that version with a fresh user account?
Thanks. I'll wait for my distro (Gentoo) to stabilise Plasma 5.27.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Hi all. 5.27 is now available on Gentoo so I'm installing that from source. I'll update here if it now handles multiple xscreens properly or not when it's completed.
I have tried with 5.27.4.1 (the currently stable version on Gentoo) and the problem is still there. I have fixed this locally by modifying plasma-workspace/shell/screenpool.cpp by telling it to ignore two of my monitors by their serial number. I'll attach my patch file. The fundamental issue is the same and that's that the code identifies monitors by QScreen.name(). This is not unique. It's possible to have two monitors on the same system with the same name. The name is the xrandr output name. I have these monitors on my system: GPU 1: DVI-I-1, HDMI-0, DVI-D-0, HDMI-1 GPU 2: DVI-I-1, DVI-D-0 Note that there are two monitors that both have the name "DV!-I-1" and "DVI-D-0". The bug is primarily in ScreenPool::handleOutputOrderChanged and handleScreenAdded. The class "OutputOrderWatcher" also has a bug because it's using the screen name to identify the screen. My patch looks in plasmashellrc for a "[IgnoredScreens]" setting which is a list of the serial numbers to ignore. I've modified handleScreenAdded and handleOutputOrderChanged to skip over QScreens that have a matching serial number. A proper fix for this is to not assume the screen name is unique and instead have a method that returns something that is unique. I recommend the screen name prefixed with the DISPLAY number (e.g. ":0.0" or "0.1"). I have used serial number because that works for me but I don't think monitors will always provide a serial number.
Created attachment 158416 [details] Patch for 5.27.4.1 to filter monitors by serial number
(In reply to Andreas Sturmlechner from comment #7) > Please create an MR over at https://invent.kde.org/plasma/plasma-workspace > instead of attaching here, it will get much more attention.
My fix as provided in the patch works for me but it's not a good general purpose fix. I filter out monitors by their serial number as that's unique, but the only easy way I could find the serial number was to add debugging in the code to output this from the QScreen instances. This isn't suitable for most people. The "Display and Monitor -> Display Configuration" system settings app correctly only shows monitors from the current xscreen. Another fix would be to just filter out monitors not in the current xscreen in the screenpool.cpp file. I looked at the QScreen class and couldn't see an easy way to get this information. Should QApp::getScreens only provide monitors in the current xscreen?
Only showing monitors from the current xscreen is probably sane given that this is what KWin and KScreen already do. But doing it in Qt sound scary and would represent a behavioral change that could break Qt-using software; maybe the solution is to filter the list that QScreen gives us in KDE code.
If it identifies monitors by something unique (e.g. the GPU or screen number they're on appended with the QScreen name) then it's likely that when plasmashell starts up it will start on both xscreens which would be a bonus. I admit though that running a multiple xscreen environment will be rare. I think the display control panel app should ask us which xscreen to run on if it detects there's more than one xscreen running. I have no idea what this would mean in a Wayland environment or whether that has a concept of "xscreen".