Created attachment 95014 [details]
There are 2 monitors. Second one is basically black screen.

I have this problem too. I have three monitors, all connected during bootup. The first one shows a background and you can right-click on it and get a menu. 

The other ones just show a black background. You can move windows there and you see a mouse cursor. But when you try to right-click in the background, you get no context menu.

When I call "killall plasmashell; sleep 3; plasmashell" on a terminal, the other two monitors get their intended background, context menu and so on after plasmashell is restarted.

So to me this looks like an issue with the order the different subsystems are started and how they depend on each other. Like the KScreen2 being started after plasmashell or something like that.

This is on Fedora 22, x86-64, Intel graphics, and plasma-workspace-5.4.2-4.fc22.x86_64
(from updates-testing).

This bug is especially annoying, because every time plasmashell starts without "seeing" the other monitors, it seems to move all the panels, desktop widgets etc. that were on the additional screens to the first one. 

So I'd have to move everything to the right position again. But since you can't move panels from one screen to another, essentially all panel settings and all settings for the widgets within the panels are lost.

So automatically restarting plasmashell during startup is not enough as a workaround, I also have to keep a good copy of ~/.config/plasma-org.kde.plasma.desktop-appletsrc and restore that.

It has happened to me too. I confirm. In my case monitors are always attached and sometimes one of them gets the black non-interactive screens. Logging out and logging back in fixes it. Not a viable solution if you have things happening that you can't interrupt....

More frequently, I get the black screen that develops after a few hours of use. Between virtual desktops. One desktop keeps all the plasmoids, panels and widgets, backgrounds and the others are black. You can still work in the black desktops and switch into and out of them with hotkeys but shell is completly gone there.

I'm Gallium for my R9 290 running in XFire; shell 5.4, KAOS distro.

I'm including some info about my system:

Octopi Sys-Info Output: http://pastebin.com/btVaPDDD
sudo blkid: http://pastebin.com/e4tzLh8Z
sudo fdisk -l: http://pastebin.com/060sNYvp
sudo journalctl -b | grep plasma:  http://pastebin.com/skvn3v9e

Is there something else you want to see?

This is similar to this unconfirmed bug:  https://bugs.kde.org/show_bug.cgi?id=333445

It might seem, also takes place accross virtual desktops. I feel that the failure that is causing the desktop to go black across virtual desktops is similar to the one causing it accross screen or they are closely related.

Another bug report, reports the same behavior as the OP: https://bugs.kde.org/show_bug.cgi?id=329958

https://bugs.kde.org/show_bug.cgi?id=345227

Here's another person reporting the same thing as the OP. They doc their Notebook to a docking bay connected to to monitors: black screen with visible mouse.

Git commit 4c4beb7a1097de831c3ec6b5f5155bb65446e155 by Aleix Pol.
Committed on 30/10/2015 at 16:04.
Pushed by apol into branch 'Plasma/5.4'.

Ensure the DesktopView has the correct size since the beginning

Otherwise ensureWindowType calls winId, triggering a window creation and
since the geometry is rect(0,0,0,0), the view is moved to the screen that
contains 0,0.

M  +1    -0    shell/desktopview.cpp

http://commits.kde.org/plasma-workspace/4c4beb7a1097de831c3ec6b5f5155bb65446e155

Hello Aleix,

thank you for looking into this.

I took this patch, and your other patch https://quickgit.kde.org/?p=plasma-workspace.git&a=commit&h=7e8aad767a250845a182166876550fb4e9701de4 and recompiled the plasma-workspace-5.4.2-6.fc22.src.rpm with it.

Unfortunately your patch does not fix or change the problem, it behaves still exactly as I described it above.

Anything I could do to help you track it down?

If you create a patch which makes plasmashell output additional debug information for this problem, I'll apply it here and send you the output.

Can confirm this in Plasma 5.5.

*** Bug 349482 has been marked as a duplicate of this bug. ***

Yes, still happens in Plasma 5.5. I've noticed that it only happens on the very first log in after a reboot through.
I also have some logs of me logging in at #359348 (if that's useful).

Same, confirm this exists in 5.5.5. Running Fedora 23 KDE spin with all updates applied.

Did somebody forget to test this?  I'd tell you what my KDE version is, but the cashew has gone missing, too.  I just installed openSUSE Leap 42.1, so maybe somebody else knows.  I did go to system-settings -> Display-and-Monitor where it dutifully shows all the correct information about both monitors.  It doesn't allow me to rotate 90 degrees, though.  (I will need that when my new monitor arrives, but not today.)

So I'd like my second monitor wall paper back, please.

I'm using 5.5.4.  Settings --> Configure Desktop --> System Settings --> Help --> About System Settings --> Version.
I think that is too hard.

Maybe that's a fluke but it seems like this happens only in some specific, albeit common, configuration. In my case I move my laptop between two desks. One has a 1080p monitor (exactly the same resolution as the laptop screen), the other has a 1680x1050 monitor. I get the black screen after login only with the former one. The latter works as expected.

Anybody with this problem and two monitors of different resolutions by any chance?

However, oddly enough, for my colleague desktop (note: not a laptop), where he has two monitors of the same resolution, everything works fine. However, being a desktop, he never connect or disconnect monitors which might be related (see bug #353052).

This all is on Fedora 22 and 23, fully up to date. Currently using plasma 5.5.5

You're right: My laptop screen uses 1920x1080 while my second desktop screen has a resolution of 1680x1050. I unfortunately do not have any external monitor with the same resolution to test.
Maybe someone has a laptop with a resolution != 1080p?

You can have the bug with other resolutions as well and also if the screens have the same resolution.
The resolution doesn't matter as far as I can tell.

That's too bad. :-(
Have you verified that this is this still the case on the same-resolution external monitors, Bernd?

It could be something else screen-configuration related through. We should collect a list of affected and non-affected screen configurations. I'll attach my `xrandr --current --verbose` when using my affected external screen.

Created attachment 98341 [details]
xrandr --current --verbose (Alexander Schlarb)

I have only "external" screens (not everybody's using a laptop :P). And they have a resolution of 1920x1200.

I'd say: Wait for Plasma 5.7 and see if it's still there, because it was said that when they can depend on Qt 5.6 (thus the next version) the multiscreen handling should improve.

(In reply to Bernd Steinhauser from comment #19)
> You can have the bug with other resolutions as well and also if the screens
> have the same resolution.
> The resolution doesn't matter as far as I can tell.

Yep scratch what I said... today the setup that used to work (which I use rarely) actually messed up (for the first time) upon login  :(

I had the same problem with docked notebook and three displays of 1920x1080 resolution on plasma 5.6.4. But only sometimes. Now, when I updated to 5.6.90, I have the problem all the time. It moves all of my widgets to one display, not even the primary one and the other displays are non-responsive black background. But they are usable in a way that I see cursor and can move the widgets and windows there.
Starting kquitapp5 plasmashell && kstart5 plasmashell works, but I have to rearrange the widgets all the time.
While Plasma 5.7 is still beta and there was a proposed change in better multi-monitor setup, maybe someone can look into it before it goes out of beta. At least for the reason that for me the problem has worsened compared to Plasma 5.6.4.

Created attachment 99713 [details]
Two black screens after plasma start

I managed to grab a photo of the situation today. That is how it looks before I run `kquitapp5 plasmashell && kstart5 plasmashell` every day.

*** Bug 364513 has been marked as a duplicate of this bug. ***

Happening here too, second monitor is black, I can't right click it, but can move windows to it. The 1st monitor's wallpaper is replaced by the second one ; if I do "killall plashmashell && plasmashell", everything goes back to normal.

More info : Plasma 5.6.90 on Arch Linux with kde-unstable repo, QT 5.7.

Happens almost all the time (I would say, 7 times / 10)

I have the same issue, with an HP and a dell external monitor. (1366x768 vs 1920 x 1200). In my case, physically disconnecting the monitor or simply turning it off fixes the external monitor "blanking"

*** Bug 365066 has been marked as a duplicate of this bug. ***

Another with the same issue ( and  more ). Logging out and back in usually fixes the unresponsive black screen. I have the added issue of any program launchers I've added to the panel or favorites seem to be gone for good.

I just went back and looked more at my missing program launchers. What I found is that a new blank panel was overlaying the original. When I deleted the panel, the one I set up with the launchers was underneath.

This happens to me since I started using Plasma 5, it's still there in plasma-5.7. It doesn't reproduce immediately, but rather after some time (0.5…couple of hours). Just like for other users, the background gets black and is not clickable, but otherwise the other monitor is fully usable.

Killing and restarting plasma helps, until next reproduction after some time.

Still occurs for me on Neon dev/stable with Plasma 5.7 and plugging in my 2x Displayport 1.2 screens. This went away for me at least when using Plasma 5.6 but now it's back.

Both screens are active but black, the mouse moves into them but nothing in there. Unplugging the cable and replugging helped the last time this happened and restarting plasma as in comment #27 another time helped  fix it.

I can confirm same problem. Three monitors and very frequently one of them is off. It is definitely Plasm a problem. Checked also in Plasma 5.7. The same configuration (hardware and software) but cinnamon desktop instead, problem disappears.

Plasma 5.7.1 still experiencing the issue

I have similar problem. After log in second screen is always black (missing background etc), but working. This happens every time. I'm using laptop (non HD) + DVI HD monitor.

It doesn't happen when I connect monitor after log in. In SDDM both laptop and external monitor have the same resolution and duplicates output. During KDE startup external monitor resolution changes to correct one and desktop area is expanded.

Latest Neon User 5.7.1 (Plasma 5.7.1, Qt 5.7) + Latest (git) mesa drivers (Intel Broadwell).

Upgraded from Plasma 5.6.5 (which didn't have this issue) to 5.7.1 on a desktop with three monitors. HDMI1 and HDMI2 have the same black, non-click-able background (but still usable) and all panels are bunched up on HDMI3. The login screen spans all three monitors as expected. Restarting plasma fixes the problem (though I have to rearrange all panels immediately afterwards).

The issue persists in 5.7.2 for me (have not seen anything related in changelog, so this is probably expected)

The same here by 5.7.2-1 in archlinux.
One screen is balck without wallpaper,the other works.
Restarting plasma or reset multi monitors setting by systemsetting may fixes it.

Exactly the same thing here, plus I'm using vertical screens. Fully updated Fedora 24,  plasma 5.71. Workaround is indeed disabling then re-enabling the second screen.

I can confirm the bug is still there.. I am running Arch linux with the last versions of plasma and I am with the same issue.. When logging into my system, my second screen is black and right clicking doesn't work. But after running "kquitapp plasmashell && kstart plasmashell" both my screen are reloaded and I can go back to my work.. So far I am running this "fix" everytime I log into my system.

Problem is still here on Fedora 24 running Plasma 5.7.1 on monitor at 1600x900 and another monitor at 1920x1080.

Here too, using neon and up to date

Persists on 5.7.3.

Could you test this with against master (either using Neon Dev Unstable, or openSUSE tumbleweed with latest git master builds)?

We have fixed a number of issues that could lead to this behaviour.

If problems persist, please attach a freshly created ~/.local/share/kscreen/kscreen.log to this bugreport.

Thanks!

I was experiencing the no desktop on second monitor issue, and I can confirm that using the latest KDE Neon Dev Unstable (built today), the issue seems to be resolved in both of the cases I tested for:
1. No desktop (black screen) on second monitor when OS is booted with secondary monitor already plugged in.
2. No desktop on second monitor when it is attached after the desktop session has loaded.

Hello everybody,

I have to confirm this issue, even I'm a little bit confused because I have two simila KDE installations, but with only one I'm experiencing this, let me be more clear.

I have two laptops:

 1 - Asus N56VZ (Intel i7-3630QM, QM, 8 GB Ram, NVIDIA GT 650M 2GB), Display Port: VGA, Ubuntu 16.04 (updated from 15.10). Laptop monitor is 1920x1080.

 2 - Asus N552VW-FI202T (Interl i7- 6700HQ, 16 GB RAM, NVIDIA GTX 960M 4GB), Display Port: HDMI, Ubuntu 16.04 (fresh installation). Laptop monitor is 3840x2160.

In both machines, I have the same KDE version. From KInfoCenter I can see the following details:
 - KDE Plasma Version: 5.5.5
 - QT Version: 5.5.1
 - Kernel Version: 4.4.0.-31-generic (machine #1), 4.4.0-34-generic (machine #2)

*** Machine #1 ***
Works great, no problem with monitors at all.

*** Machine #2 ***
is experiencing the same issues described on this thread. I can describe 3 scenarios to reproduce the bug:

 1 - If I turn on laptop #2 with the HDMI monitor powered on, sddm stucks and I cannot even see the login screen (I can still access ttys through CTRL+ALT+[1,2,3,...]).

 2 - If I turn on laptop #2 with the HDMI monitor powered off, sddm appears with the login page and I can login without problems. Once I'm in, I can turn the HDMI monitor on, in this case I get it working without the background and I can't even right-click on it, even if I can still move windows and mouse over it. In this situation, If I kill and restart plasmashell, everything goes normally: second monitor appears with background and I can right-click on it.

So, my current workaround is:
 1 - Turn on the laptop with monitor powered off:
 2 - Login in KDE environment;
 3 - Power on the monitor;
 4 - kill and restart plasmashell

You might agree with me that it's quite frustrating :(

I'd like to help you guys to find a solution on this, please tell me if you need more/different information.

Thanks a lot!

Iacopo

When testing latest Neon Dev Unstable, I haven't been affected by the bug either. But I tested it only once, it probably isn't enough to confirm that it is fixed.

What is the version for this Neon?
I am still with the problem running:

* 	plasma-desktop	5.7.3-1
* 	plasma-framework	5.24.0-1
* 	plasma-workspace	5.7.3-1

I can confirm that the bug is fixed in neon dev unstable.

@marcelo that is kde from git-master

@Nikola thanks. I'll try to test it as soon as possible.

(In reply to Iacopo Palazzi from comment #48)

I have Asus N76vz. Since I play i bit arround with plugin and plugout the vga monitor, I got trouble with dualmonitor-Setup. (BEFORE it works great).

I'll describe the behavior exactly, so maybe sombody can see where the trouble comes from:

If I boot and login into KDE, external Monitor (following named S1) shows the Menu, and a wallpaper.
Second monitor (following named S2) is black, BUT if I move the mouse to this screen, I can see the mouse-pointer. Even if right-click on S2 dosn't show any menu (seems plasma not working on this screen)

So if I unplug, and replugin the S1, both screen have a wallpaper and work like a charm. But after replugin, the menu is on S2.

Maybe this help a bit, to figure out, that it seems to be a plasma-issue?!

Just a quick comment from my side: I used to use an older (about 2011) laptop with nVidia graphics card and nouveau driver and this would happen almost always I booted up with my external screen plugged in. With my new laptop (released May 2016) and its AMD card with radeon driver it hasn't ever happened yet.

Removing the xf86-video-intel driver and using Kernel Modesetting instead seems to have fixed the problem for me...

(In reply to tromzy from comment #55)
> Removing the xf86-video-intel driver and using Kernel Modesetting instead
> seems to have fixed the problem for me...

Ok, thanks you for your reply. Can you explain, what to do to use Kernel Modesetting instead ?
Is it load by default, if I have remove xf86-video-intel ?

Created attachment 100682 [details]
attachment-12014-0.html

How come? I mean, I never really tried to read a lot about it but I always though you would not need to unninstall your driver since all the new drivers comes with mode setting by default.

That is, for example, from Arch Linux wiki:
Late KMS start
Intel, Nouveau, ATI and AMDGPU drivers already enable KMS automatically for all chipsets, so you need not install it manually.

Sent from BlueMail



On Aug 19, 2016, 7:49 AM, at 7:49 AM, Samuel Suther via KDE Bugzilla <bugzilla_noreply@kde.org> wrote:
>https://bugs.kde.org/show_bug.cgi?id=353975
>
>--- Comment #56 from Samuel Suther <s.suther@gmx.de> ---
>(In reply to tromzy from comment #55)
>> Removing the xf86-video-intel driver and using Kernel Modesetting
>instead
>> seems to have fixed the problem for me...
>
>Ok, thanks you for your reply. Can you explain, what to do to use
>Kernel
>Modesetting instead ?
>Is it load by default, if I have remove xf86-video-intel ?
>
>-- 
>You are receiving this mail because:
>You are on the CC list for the bug.

(In reply to Samuel Suther from comment #56)
> (In reply to tromzy from comment #55)
> > Removing the xf86-video-intel driver and using Kernel Modesetting instead
> > seems to have fixed the problem for me...
> 
> Ok, thanks you for your reply. Can you explain, what to do to use Kernel
> Modesetting instead ?
> Is it load by default, if I have remove xf86-video-intel ?

All you have to do is remove xf86-video-intel AND also remove /etc/X11/xorg.conf.d/20-intel.conf if you have it. Reboot and you should be using the Modesetting driver.

But is this the right thing to do?

Created attachment 100693 [details]
attachment-31005-0.html

I tried removing my xf86-video-intel and let it run only with modsetting,
and the issue was fixed for me now.

It seems a problem between the combination kde/intel driver?!? o.O

Em sex, 19 de ago de 2016 às 08:04, via KDE Bugzilla <
bugzilla_noreply@kde.org> escreveu:

> https://bugs.kde.org/show_bug.cgi?id=353975
>
> --- Comment #58 from tromzy@free.fr ---
> (In reply to Samuel Suther from comment #56)
> > (In reply to tromzy from comment #55)
> > > Removing the xf86-video-intel driver and using Kernel Modesetting
> instead
> > > seems to have fixed the problem for me...
> >
> > Ok, thanks you for your reply. Can you explain, what to do to use Kernel
> > Modesetting instead ?
> > Is it load by default, if I have remove xf86-video-intel ?
>
> All you have to do is remove xf86-video-intel AND also remove
> /etc/X11/xorg.conf.d/20-intel.conf if you have it. Reboot and you should be
> using the Modesetting driver.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

Confirm on Plasma 5.7.3
if I do "killall plashmashell && plasmashell", everything goes back to normal.

I can confirm the issue and the workaround for Plasma 5.7.4 as well.

I also can confirm that "killall plasmashell && plasmashell" fixes it.
Please note the typo in the command in #61!

I use (K)ubuntu with KDE Neon:
> lsb_release -a
No LSB modules are available.
Distributor ID: neon
Description:    KDE neon User Edition 5.7
Release:        16.04
Codename:       xenial

I tried this and it does seem to work. I had to add nohup so I could close the terminal window.

killall pasmashell && nohup plasmashell

typo,

killall plasmashell && nohup plasmashell

Playing with this a bit more I found this works best for me,

killall plasmashell; nohup plasmashell >/dev/null 2>&1 &

Now I can close the terminal when done and it does not create an ever growing nohup.out file.

killall plasmashell && kstart plasmashell

Easier and cleaner

I created a shell script with this content:
--------------------------
#! /bin/sh
killall plasmashell; plasmashell
--------------------------
Then I added a link to it to the desktop.
So I simply can run it when it is required.

Hi,

I found out "by accident" that there might be a workaround for this problem:

I run F24 KDE spin with Plasma 5.7.4 on a docked T450s with 2 Monitors. With sddm as display manager I had to restart plasmashell after every login.

Today I switched to gdm and now plasmashell works with the 2nd monitor without a problem.

( Why "by accident"? : I switched to gdm because sddm shows the login dialog on both monitors instead of just the first one. This is fixed as well as the black screen problem.)

cu,
kaasboer

Created attachment 101100 [details]
attachment-26170-0.html

Hey guys, does anyone know how I can unsub from this thread? It's great to
see you guys are so active at resolving the multi-display issues but I've
switched back to gnome (KDE was driving me too crazy... lolol).

On 15 September 2016 at 09:04, kaasboer via KDE Bugzilla <
bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=353975
>
> kaasboer <kaasboer@gmx.net> changed:
>
>            What    |Removed                     |Added
> ------------------------------------------------------------
> ----------------
>                  CC|                            |kaasboer@gmx.net
>
> --- Comment #69 from kaasboer <kaasboer@gmx.net> ---
> Hi,
>
> I found out "by accident" that there might be a workaround for this
> problem:
>
> I run F24 KDE spin with Plasma 5.7.4 on a docked T450s with 2 Monitors.
> With
> sddm as display manager I had to restart plasmashell after every login.
>
> Today I switched to gdm and now plasmashell works with the 2nd monitor
> without
> a problem.
>
> ( Why "by accident"? : I switched to gdm because sddm shows the login
> dialog on
> both monitors instead of just the first one. This is fixed as well as the
> black
> screen problem.)
>
> cu,
> kaasboer
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

(In reply to kaasboer from comment #69)
> Hi,
> 
> I found out "by accident" that there might be a workaround for this problem:
> 
> I run F24 KDE spin with Plasma 5.7.4 on a docked T450s with 2 Monitors. With
> sddm as display manager I had to restart plasmashell after every login.
> 
> Today I switched to gdm and now plasmashell works with the 2nd monitor
> without a problem.
> 
> ( Why "by accident"? : I switched to gdm because sddm shows the login dialog
> on both monitors instead of just the first one. This is fixed as well as the
> black screen problem.)
> 
> cu,
> kaasboer

How did you do this?

I tried
dpkg-configure gdm
as well as
dpkg-configure lightdm
but with both the DE did not start anymore, both screens stayed black!

Note:
The issues with the second screen black only started after I installed KDE Neon on top of Kubuntu. How ever I also installed a virgin Neon Distribution (Ubuntu based) and had the same issue.

Created attachment 101118 [details]
ZIP file containing captured debug info and configs

I may have figured out what is causing this issue. I ran

xrandr --verbose

a few times and diffed the output between reboots. As it turns out, the reported CRTC for the same external monitor changes randomly between reboots. Disabling and re-enabling the display restores the CRTC reported by xrandr.  This is what I see happening:

I start out with a correctly operating dual-screen setup, two identical displays attached to the dock of my laptop, desktop extends across both screens.
After reboot, I often see the following things happening:

1. login screen and KDE splash screen extends across both screens, as it should. Desktop appears, one of the screens is black. I can move the mouse to the black screen, but no response to mouse clicks.
2. Open display config. Disable secondary monitor. While doing this, the display resolution for the now disabled screen is reduced.
3. Enable the display again. Desktop extends again to both displays
4. Restore resolution of the just enabled display

I captured the output of xrandr, kscreen, and the changes in the kscreen display configuration file after each of the above steps 1 to 4, see attachments. You can see how the  CRTC changes after disabling and re-enabling the secondary display.

Hopefully, this will pin down what the source of the problem is.

I'm seeing this same behavior with plasma 5.8 beta.  A black screen on one monitor, and the only fix is to restart plasma.

I just installed a daily snapshot of Kubuntu 16.10 (17.09.2016) and discovered that it is also broken there! To solve it I had to restart plasmashell. Since it was a virgin installation, there where no old config files involved.

One other data point: I swapped to LXQT using kwin as the window manager.  Everything was fine there, so this does not seem to be kwin related.

This is happening to me as well - except my primary monitor (Dell XPS15 QXHD screen). Logging out and logging back in after boot fixes the issue, or killing plasma and starting it again. Haven't tried turning the monitor off and back on yet though

I have a similar problem in the Manjaro KDE 16.08. After logout, all is well
Plasma Version 5.7.5
KDE Frameworks Version 5.26.0
QT 5.7

Hi, I'm experiencing this problem as well, with Fedora 24, KDE 5.7.5.
2nd monitor in black, no context menu.

(In reply to Yvan Broccard from comment #79)
> Hi, I'm experiencing this problem as well, with Fedora 24, KDE 5.7.5.
> 2nd monitor in black, no context menu.

Did you try to unninstall your video driver? 

I tried removing my xf86-video-intel and let it run only with modsetting,
and the issue was fixed for me now.

(In reply to Yvan Broccard from comment #79)
> Hi, I'm experiencing this problem as well, with Fedora 24, KDE 5.7.5.
> 2nd monitor in black, no context menu.

Did you try to unninstall your video driver? 

I tried removing my xf86-video-intel and let it run only with modsetting,
and the issue was fixed for me now.

I've seen this with intel, modesetting and AMDGPU (running on either card.)

Generally, I can recover by switching to a console (Alt+F2) and then back, though monitor 2 almost always loses its settings (wallpaper and so on.)

This is a show stopper.  I switched to lxqt until this is fixed.

LXQT doesn't show this.  FWIW.

(In reply to Marcelo Rocha from comment #81)
> Did you try to unninstall your video driver? 
> 
> I tried removing my xf86-video-intel and let it run only with modsetting,
> and the issue was fixed for me now.

Let's try to avoid confusion, this is a KDE bug, not a video driver bug. I don't say switching to modesetting didn't helped you (especially for Skylake many distros are switching to modesetting over intel, including Fedora 24 which uses modesetting only by default), but the black screen issue might have been a fluke.

It has also been officially confirmed that Plasma releases before 5.7 has sup-par multi screen support. The first system change a user might attempt to fix this problem should be trying Plasma 5.8, not messing with the video driver (it's messy, a lot of time is usually needed and here it's not the most likely cause). See also https://vizzzion.org/blog/2016/09/lts-releases-align-neatly-for-plasma-5-8/ and let me quote Sebastian Kügler's comment "Especially support for multi-screen systems in 5.7 is sub-par, those users would really benefit from getting Plasma 5.8."

I had this issue, and indeed, upgrading to Plasma 5.8 (on KDE Neon) solved the problem for me.

(In reply to Enrico Tagliavini from comment #83)
> (In reply to Marcelo Rocha from comment #81)
> > Did you try to unninstall your video driver? 
> > 
> > I tried removing my xf86-video-intel and let it run only with modsetting,
> > and the issue was fixed for me now.
> 
> Let's try to avoid confusion, this is a KDE bug, not a video driver bug. I
> don't say switching to modesetting didn't helped you (especially for Skylake
> many distros are switching to modesetting over intel, including Fedora 24
> which uses modesetting only by default), but the black screen issue might
> have been a fluke.
> 
> It has also been officially confirmed that Plasma releases before 5.7 has
> sup-par multi screen support. The first system change a user might attempt
> to fix this problem should be trying Plasma 5.8, not messing with the video
> driver (it's messy, a lot of time is usually needed and here it's not the
> most likely cause). See also
> https://vizzzion.org/blog/2016/09/lts-releases-align-neatly-for-plasma-5-8/
> and let me quote Sebastian Kügler's comment "Especially support for
> multi-screen systems in 5.7 is sub-par, those users would really benefit
> from getting Plasma 5.8."

Yes, I got you.

That's true, this is not a solution, but was a way to get rid of it while it was not fixed yet.

Better than always have to kill something to have my dual monitor working after every boot.

Just a quick walk around.

I occasionally see it on Fedora 24 if the screen locks itself and turns off. The laptop screen on a dual head docked display then doesn't come back to life. My workaround (until I get Plasma 5.8 :-) ) is, using the working monitor, resize the laptop display. That seems to kick it back to life and then I resize it back to normal.

I installed Kubuntu 16.10, at my Dell Inspiron 7720 laptop, both clean & upgrading 16.04 and I had a very similar behavior with the external monitor. At every reset Plasma 7.5 was loosing its settings, it was confusing the main display, the Task manager Panel was in the wrong screen, the icons loosing their postion etc.

Since last upgrade on Manjaro-Linux, the error is gone.

Upgrading to plasma 5.8 did not fix this for me.

I found an easy way to reproduce it though.  With two monitors, put your computer into suspend.  Now, turn off one of the monitors and resume, then turn on the second monitor once resume is complete.  I get either a blank screen on monitor two, or I get the default wallpaper.  Switching to a VT and back will generally fix the blank screen.

This is not a video driver bug, or at least I can reproduce it across multiple drivers (Intel, AMD and modesetting), two different video chipsets (Intel and AMD) and with Mesa/Xorg at head or at last stable release.  I believe this is a Plasma problem.

I can confirm that this problem persists in Plasma 5.10.3, KDE Frameworks 5.35.0, Qt 5.7.1 on Ubuntu 17.04 (with Kubuntu Plasma Desktop backport). I have 4 monitors, 3 of which are connected to a discrete NVIDIA GeForce GTX 750 (Driver Version 381.22) via HDMI for 2 and DVI-D for the 3rd, the last monitor is connected via HDMI to the integrated Intel graphics (Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller using i915 driver).

So, the issue for crops up when I put the computer into suspend mode, turn off the 4th monitor (as it is a SHARP LCD TV with a low-light, black screen--not completely off--suspend mode), resume the computer, get to login screen and turn the monitor back on. This screen will sometimes (not always) have lost the background and starts to dim when not focused. I can click for context menu, move apps to the screen, etc. but the plasma shell is gone.

Incidentally, there is another issue where when I come back from suspend mode, even without having turned off the monitor, icon text on the desktop gets some funky artifacts like this http://i.imgur.com/59bh5b8.png. Sometimes it is event worse, looking like complete white noise.

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 set the bug status 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!

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now 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

Thank you for helping us make KDE software even better for everyone!

For those still experiencing this issue, we are tracking it as a new bug report now: Bug 442826.

Actually never mind, let's re-open this since it's the oldest one.

*** Bug 442826 has been marked as a duplicate of this bug. ***

*** Bug 448503 has been marked as a duplicate of this bug. ***

*** Bug 443274 has been marked as a duplicate of this bug. ***

*** Bug 369450 has been marked as a duplicate of this bug. ***

*** Bug 381270 has been marked as a duplicate of this bug. ***

*** Bug 399216 has been marked as a duplicate of this bug. ***

*** Bug 419518 has been marked as a duplicate of this bug. ***

*** Bug 426886 has been marked as a duplicate of this bug. ***

*** Bug 440621 has been marked as a duplicate of this bug. ***

*** Bug 440918 has been marked as a duplicate of this bug. ***

*** Bug 442438 has been marked as a duplicate of this bug. ***

*** Bug 442455 has been marked as a duplicate of this bug. ***

*** Bug 444198 has been marked as a duplicate of this bug. ***

*** Bug 446594 has been marked as a duplicate of this bug. ***

*** Bug 448250 has been marked as a duplicate of this bug. ***

*** Bug 448963 has been marked as a duplicate of this bug. ***

*** Bug 449112 has been marked as a duplicate of this bug. ***

Today it did it again. But since my latest comment I had added a dummy widget (a clock) on my secondary monitor.

The secondary monitor is black but the widget moved to my main screen.
When I rebooted, the secondary monitor came back and the widget with it.

*** Bug 449292 has been marked as a duplicate of this bug. ***

Same here: two screens, one of them has sometimes after a cold start a black background without any interactions (contextmenu).
As a workaround "kquitapp5 plasmashell; kstart5 plasmashell" brings the desktop back.

Running Kubuntu 21.10, plasmashell 5.22.5

Shouldn't this be in the 15-minute bug initiative? It is something users encounter directly after login.

It seems to happen more regularly again for me since 5.23.5 and frameworks 5.90.0

It's marked as VHI, which means that it's even higher priority than the 15 minute bug initiative.

*** Bug 449349 has been marked as a duplicate of this bug. ***

I also have this issue, directly caused by the new Primary Monitor feature with KDE/Wayland. 

When waking my PC from Idle/Standby, and using the new primary monitor feature, my secondary monitor loses interactivity and the wallpaper is black. Enabling and disabling the monitor or power cycling it returns the monitor to the appropriate state. My main monitor takes awhile to wake from standby and I think that is the cause of this issue, as my desktop first appears on the secondary monitor and then stuff gets shifted over, thus the secondary monitor has this problem. I have a Samsung Odyssey G7, 240Hz @ 1440p as the primary (notorious for taking a long time to wake) and a HP Omen 165Hz 1440p monitor as the secondary. Both connected via displayport.

Since my main monitor takes forever to wake, on the previous KDE version I'd have to power cycle my monitor to get all my taskbars and widgets into the correct place, but now, while my main monitor does indeed remain primary, the second becomes non-interactive, so in a sense I feel as if I traded one issue for another. 

Running plasma-shell built with "kdesrc-build --include-dependencies plasma-desktop" as of a few days ago, happens on the beta too.

Operating System: Arch Linux
KDE Plasma Version: 5.23.80
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.2
Kernel Version: 5.16.2-xanmod1-ga17cd44d2cd0 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 6900 XT

(In reply to kdebugreport from comment #118)

I have found a workaround. I've made my secondary monitor my primary, and just moved my taskbars and widgets.

I dont know if this is related, but since upgrading to "5.23.5-2" (manjaro), my taskbar seems to graphically freeze often

behavior of what i mean:
- the task bar graphically freezes at some point (no updates graphically anymore, like the clock)
- functionality still works (like hover and clicking on like the clock to open the small calender and clicking on the start-menu)
- if a program opens or closes, the task-bar does not update to show the change

Not related; that is most likely Bug 449163.

(In reply to Nate Graham from comment #121)
> Not related; that is most likely Bug 449163.

yes can confirm that is the issue i meant - thanks

If it helps I can confirm comment #118, I'm currently running Plasma 5.24.1. It seems that this issue has shown up with the 5.24 upgrade, before this it worked fine.

One easier way to reproduce this from me:
1) Set computer not to sleep when lid is closed.
2) Close lid, the laptop display is turned of.
3) At this point the desktop layout(?) panel and everything moves to the secondary display and the layout of the secondary display goes away.
4) Open the lid back, the laptop display is turned on
5) The layout moves back to the laptop display but the secondary display is now blank.
6) Plug the secondary display out and plug it back in and everything is back to normal.

I am on Fedora 35 with KDE 5.24.2
I have two monitors, connected to the same Graphic adapter (Radeon RX 580) and they are utilizing one HDMI and one Display Port connection.
I disconnect (power off) my primary monitor and the other one remains as it was.
When I power on again my primary monitor, all my monitors are as before except:

- No wallpapers, only black background on both but at some point the wallpaper on the primary monitor will be visible again
- My secondary monitor (the one that I didn't power off) does not accept right clicks on the desktop surface
- My primary monitor accepts right clicks on the desktop surface and I can open the "Configure Desktop and Wallpaper" window. But when I do that, opens two (2) to four (4)  Configure Desktop and Wallpaper windows, one above the other. While these are opened I can see for a split second the wallpaper of my primary monitor disappearing and reappearing.

One way to restore everything, as they were is:

Open the Display settings, disable and then enable again, the secondary monitor. 
Then, everything will be fine, but while I can now open the "Configure Desktop and Wallaper" window on my secondary monitor without any issue, if I try to open it on my primary monitor, immediately I am back to as if I had disconnected the primary monitor situation, which means:

- No wallpapers, only black background on both but at some point the wallpaper on the primary monitor will be visible again
- My secondary monitor (the one that I didn't power off) does not accept right clicks on the desktop surface
- My primary monitor accepts right clicks on the desktop surface and I can open the "Configure Desktop and Wallpaper" window. But when I do that, opens two (2) to four (4)  Configure Desktop and Wallpaper windows, one above the other. While these are opened I can see for a split second the wallpaper of my primary monitor disappearing and reappearing.
  
The only real solution is to log off and log on again to my Desktop

Here's what "fixed" the issue for me, at least for now:

* Log out of KDE

* Switch to TTY2

* sudo systemctl stop sddm

* rm -rfv ~/.local/share/kscreen

* kbuildsycoca5 --noincremental

* sudo systemctl restart sddm

* Log back in and redo configuration under Settings -> Display and Monitor

Something's going on with systems that were installed with earlier versions of KDE (e.g, 5.23 or previous), and then updated their software to KDE 5.24, in which current configurations (such as those saved under the folder ~/.local/share/kscreen) causes issues with multiple displays / laptop lid actions.

(In reply to flan_suse from comment #125)
> Here's what "fixed" the issue for me, at least for now:
> 
> * Log out of KDE
> 
> * Switch to TTY2
> 
> * sudo systemctl stop sddm
> 
> * rm -rfv ~/.local/share/kscreen
> 
> * kbuildsycoca5 --noincremental
> 
> * sudo systemctl restart sddm
> 
> * Log back in and redo configuration under Settings -> Display and Monitor
> 
> Something's going on with systems that were installed with earlier versions
> of KDE (e.g, 5.23 or previous), and then updated their software to KDE 5.24,
> in which current configurations (such as those saved under the folder
> ~/.local/share/kscreen) causes issues with multiple displays / laptop lid
> actions.

I tried this, it didn't fix it for me, same issue.

(In reply to H.G.Blob from comment #126)
> (In reply to flan_suse from comment #125)
> > Here's what "fixed" the issue for me, at least for now:
[...]
> I tried this, it didn't fix it for me, same issue.

Neither for me, the hack does not fix the issue. I can also confirm  comment #118: the black background/missing context menu always happens on the screen which is flagged as "primary".

There are so many bugs tagged as duplicate of this bug which stems from 2015, however, for me the symptoms are new. Is it really the case that this is a sooooo long running never-fixed bug which reaches back to 2015? I do not quite think so ... at least for me the problem did not occur before this year, always running which recent kde/plasma versions ...

I can consistently reproduce this bug. My two screens are connected to two PCs and I toggle between those with a 2x2 KVM. Every time I switch from my KDE desktop PC to my Windows Laptop and then back, the background is gone and right-clicking doesn't work (on the black background). This wasn't always the case!

Until a few of weeks ago, I was plagued by this bug (after switching back and forth; a second back and forth always fixed it):
https://bugs.kde.org/show_bug.cgi?id=427278
After that bug got fixed, I am now getting the bug described here.

FYI - still see same bug in 5.24.3

My case 2 4k monitors one on USB-C on on HDMI. Fully updated Arch linux and using wayland.

After any inactivity, wake up with keyboard or mouse and 100% of time one monitor is normal and other has black background (does have panel) - restarting plasmashell gets things back again until no activity followed by activity.

This started sometime around 5.24 - definitely started not long ago.

Facing same issue 

Mobo Asus ROG Strox B550F Wifi
Processor : AMD 5800x
GPU : Sapphire AMD 6600 8GB
Memory : Corsair Vengeance 2133  16GB  x 2 

OS : Fedora 35 (clean install)
Kernel : 5.16.17-200.fc35.x86_64
KDE Plasma : 5.24.3
Session Type : Wayland
DVI : 32" LG on 1 

After returning from standby, the left screen is blank with right click not working. I cant move windows to the screen and the window works ok, but screen remains blank. The sound is also disrupted. The sound output is through Optical to Monitor and from audio jack of monitor to speakers. I have to change the audio setting back to HDMI after some time if the port reappears.

I want to add a comment here.

After the loss of dual monitor in KDE Plasma, I swtched the display manager to GDM.

The issue with KDE Plasma session stopeed occuring. One screen goes blank, the other screen has some flicker and then it stabilizes and becomes responside. Both screens are active with backgrounds and right click functinality enabled. Not sure what solves this. 

Also noticed with SDDM, that both screens had the password prompt when returning from standby, GDM has it on only one. So is this a KDE Plasma desktop bug or a bug in SDDM ?

I tried lightdm - and if i manually start light-locker everything is fine.
If I leave the plasma wayland session - then the plasma locker kicks in and things are once again broken.

So this tells me that is the trigger/source of the problem.

That said - how do I replace the plasma locker with light-locker - anyone know ?

My comment above may not be right - trigger may relate to hardware sleep/wake as well. If I turn off the plasma screen locker that might provide additional information.

Reporting back - with no screen lock at all - problem persists. And same with sddm or lightdm.

Clearly seems related to powering off and resuming of monitors for our case anyway.

I suppose since gdm is wayland capable while sddm and lightm both use X - that could be playing into this.
Curious that a new display manager like sddm is built solely on old X technology instead of wayland come to think of it.

*** Bug 439397 has been marked as a duplicate of this bug. ***

Created attachment 148094 [details]
Zombie Desktop on Virtual Desktop 2, 3, and 4

Comment on attachment 148094 [details]
Zombie Desktop on Virtual Desktop 2, 3, and 4

I am getting zombie desktop on most of my virtual desktops.
Please see attached image.


Operating System: Manjaro Linux
KDE Plasma Version: 5.24.3
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.3
Kernel Version: 5.16.14-1-MANJARO (64-bit)
Graphics Platform: X11
Processors: 8 × AMD FX(tm)-8350 Eight-Core Processor
Memory: 15,6 GiB of RAM
Graphics Processor: AMD Radeon Pro WX 3200 Series

I'm also having this issue for a while now. Happens like every 5 boots, or something like that.

I'm on Manjaro KDE, two 1080p monitors, the primary over HDMI, and the secondary (the one where this issue happens) over DVI. Using Nvidia proprietary drivers (video-nvidia).

Operating System: Manjaro Linux
KDE Plasma Version: 5.24.3
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.3
Kernel Version: 5.15.28-1-MANJARO (64-bit)
Graphics Platform: X11
Processors: 4 × AMD Ryzen 3 2200G with Radeon Vega Graphics
Memory: 15.6 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 970/PCIe/SSE2

I am also having this issue. It is beyond frustrating. In my case, sometimes reconnecting a monitor causes Plasma to lock up. Only a forced reboot is able to resolve this. This did not use to happen.

(In reply to Micael Jarniac from comment #139)
> I'm also having this issue for a while now. Happens like every 5 boots, or
> something like that.
> 
> I'm on Manjaro KDE, two 1080p monitors, the primary over HDMI, and the
> secondary (the one where this issue happens) over DVI. Using Nvidia
> proprietary drivers (video-nvidia).
> 
> Operating System: Manjaro Linux
> KDE Plasma Version: 5.24.3
> KDE Frameworks Version: 5.91.0
> Qt Version: 5.15.3
> Kernel Version: 5.15.28-1-MANJARO (64-bit)
> Graphics Platform: X11
> Processors: 4 × AMD Ryzen 3 2200G with Radeon Vega Graphics
> Memory: 15.6 GiB of RAM
> Graphics Processor: NVIDIA GeForce GTX 970/PCIe/SSE2

I've updated my system recently, and am still having these issues. Couldn't figure out how to edit the comment, so am commenting again with the updated info:

Operating System: Manjaro Linux
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3
Kernel Version: 5.17.1-3-MANJARO (64-bit)
Graphics Platform: X11
Processors: 4 × AMD Ryzen 3 2200G with Radeon Vega Graphics
Memory: 15.6 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 970/PCIe/SSE2

*** Bug 452786 has been marked as a duplicate of this bug. ***

*** Bug 452871 has been marked as a duplicate of this bug. ***

Still the bug is not fixed. Here I have Gentoo

Plasma: 5.24.4
Frameworks: 5.93.0
AMD Ryzen 5 3400G with Radeon Vega Graphics (no other GFX card)

When I switch off the monitors manually or after they went to sleep:

- at least one of the two connected monitor is non-responsive and black
- sometimes the button bar has vanished. It reappears when I power cycle the respective monitor
- button bar seems to reappear on the non-primary display. Background icons appear on the non-primary display
- primary display is  black, when  I switch this broken "primary display" to the other monitor then the new "primary display" goes black.
- windows are relocated wildly to one of the monitors when  switching them off (probably a timing issuee ... moving the windows to a screen which still appears active
- windows height is reduced to minimum and not restored when switching the monitors on

Alll this was not happening until around start of January this year. This is why I do not believe that this is still the same issue as it was back in 2015 when this bug-report was created.

(In reply to Claus-Justus Heine from comment #144)
> Alll this was not happening until around start of January this year. This is
> why I do not believe that this is still the same issue as it was back in
> 2015 when this bug-report was created.

I second that, I have this bug, very similar to what Claus-Justus described since a few weeks on Fedora 35 on Intel GPU. It started appear after either a Plasma 5.24 update or a kf 5.91 update. Before this I never had this bug for several years.

I too have had a similar issue for a few months. In addition to the suspend/resume scenario described in other comments, very similar symptoms sometimes occur when launching applications such as Firefox and Okular. This makes me suspect that it may be related to some kind of initialization or state change of hardware acceleration.

(In reply to Claus-Justus Heine from comment #144)
> Still the bug is not fixed. Here I have Gentoo
> 
> Alll this was not happening until around start of January this year. This is
> why I do not believe that this is still the same issue as it was back in
> 2015 when this bug-report was created.

i can also confirm this on my systems, the original issue (black desktop and unresponsive desktop) were fixed for me by upgrading from kde 5.23 to 5.24 and first happened in ~5.20, but since 5.24, after unlocking the display again makes black bars appear, sometimes covering just a bit and sometimes covering the whole display and sometimes also flickering, also for me clicking or bringing a window on the screen where the black bars / flickering happen stops it (but if its just half a display, like for example 2 windows side-by-side, then just clicking one of these windows will not fix the other window and the other window has to also be clicked)

my system:
Operating System: Manjaro Linux
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3
Kernel Version: 5.17.1-3-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-7700K CPU @ 4.20GHz
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX Vega

my setup:
1 hdmi display (left) 1080p display
1 displayport display (middle) 1440p display (primary)
1 displayport display (right) 1080p display

also in my case the black bars / flickering happen rarely on the primary display
and the issue is more often when the output has been put to sleep and gets reactivated again (note: i do not mean hibernate/sleep, i mean that output has been put to sleep "Screen Energy Saving")

(In reply to hasezoey from comment #147)
> (In reply to Claus-Justus Heine from comment #144)
> > Still the bug is not fixed. Here I have Gentoo
> > 
> > Alll this was not happening until around start of January this year. This is
> > why I do not believe that this is still the same issue as it was back in
> > 2015 when this bug-report was created.
> 
> i can also confirm this on my systems, the original issue (black desktop and
> unresponsive desktop) were fixed for me by upgrading from kde 5.23 to 5.24
> and first happened in ~5.20, but since 5.24, after unlocking the display

Just to clarify: the bug is still _not_ fixed. I'm currently running 5.24.X and it exhibits just the same buggy behaviour. According to the git-log of the Gentoo packages it seems they switched to 5.23 by the end of last year. So from my experience I would assume the bug probably started with 5.23 and is still unfixed.

From my side, I can confirm the related problems have been fixed in the latest 5.24 dot releases. However, to make this happens, I had to reset the KDE related conf (and I took the initiative to reset all the KDE apps conf too, in order to start clean, since I was using the same install since 2018 already). I assume there was some leftovers from previous 5.x versions making KWin or related to misbehave.
```
#!/usr/bin/env bash
cd ~/
rm -rv .kde
rm -rv .cache/plasmashell*
rm -rv .cache/org.kde.dirmodel-qml.kcache
rm -rv .cache/kioexec/ .cache/krunner/ .cache/ksycoca5*
rm -rv .cache/krunnerbookmarkrunnervirefoxdbfile.sqlite
rm -rv .config/plasma*
rm -rv .config/kde*
cd .local/
rm -rv kate/ kded5/ klipper/ knewstuff3/ kscreen/ konsole/ kwalletd/ ksysguard/ kmail2/ kcookiejar/ kactivitymanagerd/
cd share/
rm -rv dolphin kate kcookiejar kded5 keyrings klipper kmail2 knewstuff3 konsole kscreen ksysguard kwalletd kxmlgui5 plasma_engine_comic plasma plasma_notes org.kde.gwenview
cd ~/.config/
rm -rv akonadi* KDE kconf_updaterc baloo* dolphinrc drkonqirc gwenviewrc kmail2rc k*rc katemetainfos
```
[src.](https://forum.manjaro.org/t/how-reset-all-kde-settings/21518/3)
My KDE daily driver machine is a DELL Inspiron 5579 with i7-8550U and Intel UHD 620 as "graphic" card.

(In reply to wget from comment #149)
> From my side, I can confirm the related problems have been fixed in the
> latest 5.24 dot releases. However, to make this happens, I had to reset the
> KDE related conf (and I took the initiative to reset all the KDE apps conf
> too, in order to start clean, since I was using the same install since 2018
> already). I assume there was some leftovers from previous 5.x versions
> making KWin or related to misbehave.
> ```
> #!/usr/bin/env bash
> cd ~/
> rm -rv .kde
> rm -rv .cache/plasmashell*
> rm -rv .cache/org.kde.dirmodel-qml.kcache
> rm -rv .cache/kioexec/ .cache/krunner/ .cache/ksycoca5*
> rm -rv .cache/krunnerbookmarkrunnervirefoxdbfile.sqlite
> rm -rv .config/plasma*
> rm -rv .config/kde*
> cd .local/
> rm -rv kate/ kded5/ klipper/ knewstuff3/ kscreen/ konsole/ kwalletd/
> ksysguard/ kmail2/ kcookiejar/ kactivitymanagerd/
> cd share/
> rm -rv dolphin kate kcookiejar kded5 keyrings klipper kmail2 knewstuff3
> konsole kscreen ksysguard kwalletd kxmlgui5 plasma_engine_comic plasma
> plasma_notes org.kde.gwenview
> cd ~/.config/
> rm -rv akonadi* KDE kconf_updaterc baloo* dolphinrc drkonqirc gwenviewrc
> kmail2rc k*rc katemetainfos
> ```
> [src.](https://forum.manjaro.org/t/how-reset-all-kde-settings/21518/3)
> My KDE daily driver machine is a DELL Inspiron 5579 with i7-8550U and Intel
> UHD 620 as "graphic" card.

Unfortunately, this did not work for me. I've gone as far as reinstalling all of Plasma to no avail.

(In reply to naumenko.dmitriy from comment #150)
> (In reply to wget from comment #149)
> > From my side, I can confirm the related problems have been fixed in the
> > latest 5.24 dot releases. However, to make this happens, I had to reset the
> > KDE related conf (and I took the initiative to reset all the KDE apps conf
> > too, in order to start clean, since I was using the same install since 2018
> > already). I assume there was some leftovers from previous 5.x versions
> > making KWin or related to misbehave.
> > ```
> > #!/usr/bin/env bash
> > cd ~/
> > rm -rv .kde
> > rm -rv .cache/plasmashell*
> > rm -rv .cache/org.kde.dirmodel-qml.kcache
> > rm -rv .cache/kioexec/ .cache/krunner/ .cache/ksycoca5*
> > rm -rv .cache/krunnerbookmarkrunnervirefoxdbfile.sqlite
> > rm -rv .config/plasma*
> > rm -rv .config/kde*
> > cd .local/
> > rm -rv kate/ kded5/ klipper/ knewstuff3/ kscreen/ konsole/ kwalletd/
> > ksysguard/ kmail2/ kcookiejar/ kactivitymanagerd/
> > cd share/
> > rm -rv dolphin kate kcookiejar kded5 keyrings klipper kmail2 knewstuff3
> > konsole kscreen ksysguard kwalletd kxmlgui5 plasma_engine_comic plasma
> > plasma_notes org.kde.gwenview
> > cd ~/.config/
> > rm -rv akonadi* KDE kconf_updaterc baloo* dolphinrc drkonqirc gwenviewrc
> > kmail2rc k*rc katemetainfos
> > ```
> > [src.](https://forum.manjaro.org/t/how-reset-all-kde-settings/21518/3)
> > My KDE daily driver machine is a DELL Inspiron 5579 with i7-8550U and Intel
> > UHD 620 as "graphic" card.
> 
> Unfortunately, this did not work for me. I've gone as far as reinstalling
> all of Plasma to no avail.

Yeah, I completely rebuilt / re-installed 2 systems with Arch 3 or so weeks ago. They're both AMD GPUs and plugged into the same 2 monitors. The one with HDMI connections has the problems described here. The DP port does not. It seems something (plasma, X, etc...???) doesn't wait long enough to see if the screen is still there when coming out of monitor "off" mode and then moves everything to "one" screen.  I don't put my systems to sleep, just the monitors. 

This exact problem didn't start for me until the last 6 months or so (also Arch based) and it's been pretty consistent.

Alex / Nate - can either of you provide any information on where things stand with regard to repairing this (annoying) lil bug?

thanks.

Not really, no. Marco is probably the only one who can investigate this and he's currently busy with other things. I know it's super annoying, but patience is appreciated.

Understood and thanks for feedback.

I can confirm that I have just had this same issue.
OS: Gentoo Linux 5.15.32-gentoo-r1 #1 SMP Thu Apr 7 13:56:33 NZST 2022 x86_64 Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz GenuineIntel GNU/Linux
GPU: Nvidia 750Ti
Screen layout on xscreen 0: 4 monitors in a grid in this layout:
1680x1050+240+30
1920x1080+0+1080
1920x1080+1920+0
1920x1080+1920+1080

Screen layout on screen 1: 2 monitors:
1680x1050+0+0
1920x1080+0+1050

The plasma desktop loads on the left two monitors but won't load on the right two. The primary monitor is the bottom right monitor. I can drag windows to all monitors ok, but no widgets display and the desktop wallpaper isn't showing. It's as if plasma-desktop isn't running on those two monitors.
This started happening after updating from plasma 5.23.5 to 5.24.4-r1.

I have a separate xscreen with two monitors on which I don't run plasma. I have noticed that plasma decided to run on that xscreen. This is a change in behaviour.
Does anyone know how to make plasma only run on xscreen 0 and not on xscreen 1?

*** Bug 453643 has been marked as a duplicate of this bug. ***

Just an update for everyone: we think there is a decent chance this is fixed in Plasma 5.25 and are working on backporting a major multimonitor refactor to 5.24. In the meantime, if anyone affected would test with Plasma 5.25 (AKA current git master) that would be lovely.

Apologies for the duplicate! I'll work on testing master on my machine.

I've just built and tried the newest Plasma from git. It seems to be consistently crashing on login and whenever my screens go to sleep for a while (doesn't happen when I wake them up relatively quickly). Good thing is that so far, after each crash Plasma has been able to restart and recover without messing up wallpapers and the desktop layout. Does this behavior deserve its own bug report?

Since restarting plasmashell always "fixed" the desktop I don't think your test validates that anything is fixed.
I suppose there are 2 possibilities:

(i) If the crash is a result of the "fix" and now crashes instead then bug is not fixed.
(ii) Crash is unrelated, so cannot tell if the bug is fixed or not yet  (bad build, new bug, etc).

Either way, until it stops crashing we cannot tell which of the 2 is happening.

Has anyone else managed to get git master fully built with all deps updated etc and test it?

Forgot to say (sorry for being obvious) -but  the fact that it crashes when being woken up after things go to sleep - suggests that this is perhaps case (i)

I'm glad to hear the desktop issues are fixed for you! Let's get another bug report for the crash, please.

I think Gene might be right. The crash may be just partially covering up the symptoms of this bug by restarting the Plasma automatically. After a couple of attempts more (and perhaps longer periods of screen sleep), I managed to get some missing wallpapers etc., so sadly I can't say that the problem is gone. At least the panel layout seems to be always correct now (probably due to the restarts)

I'll be opening a bug report for the crash shortly.

Could this be a duplicate of 427861 (https://bugs.kde.org/show_bug.cgi?id=427861)? Now that the crash isn't happening for this one, they appear to be the same issue.

Never mind the crash I was talking about - it seems to be a problem with my build.

I've had trouble building master, and I haven't had time yet to troubleshoot, but I am happy to report that switching from X11 to Wayland appears to solve the problem on my machine. (5.24.5)

Scratch that. Got master built, and I'm seeing the same issue when I login with X11. Attempting Wayland on master nets me a blank screen, so I haven't been able to confirm that the Wayland fix (?) works for me beyond 5.24.5.

*** Bug 454258 has been marked as a duplicate of this bug. ***

*** Bug 426644 has been marked as a duplicate of this bug. ***

Hi @Nate:
Results of testing with Archlinux 5.24.90 from kde-unstable repo.

Good:
 - Both monitor desktops continue to work after idle and wake cycle (yay) which means the major bug is fixed. 

Bad (ish):
 - After idle/resume all windows are pushed to 1 of the 2 monitors.  This has one usb-c and one hdmi - so feels like timing issue to me
 - Tons of messages logged to journal 
   - plasmashell[xxx]: IPDL protocol error: Handler returned error code!
     plasmashell[xxx]###!!! [Parent][DispatchAsyncMessage] 
            Error: PClientManager::Msg_ExpectFutureClientSource Processing
            error: message was deserialized, but the handler returned false (indicating failure)

Per my last test - this is wayland desktop started by sddm running wayland. So no Xorg involved anywhere.

I'm running 5.24.90 from the neon beta repository and it seems that the new changes  are causing my plasma to crash every time I unplug a monitor, so behavior has changed.

I can regularly crash plasmashell by simply editing (1 of the 2)  panel and adding (or trying to add) applications from kmenu - not convinced this wasn't commonplace in released version though. 

I did this as after updating to 5.24.90 all customized panel settings were lost. i gave up after multiple tries,  added default panel and use quick launcher now - which at least don't crash and vanish :)

This is beta and bugs are expected.

I'm running Gentoo and after upgrading plasma from 5.24.4 to 5.24.5 I'm facing the same issue as before: I run two xscreens and I only want plasma to run on xscreen0. It now tries to run on both xscreens and does so incorrectly: xscreen0 has 4 displays and xscreen1 has 2. Now it only runs on two of the screen0 displays and on the 2 screen1 displays.

How do I tell plasma to leave xscreen1 alone? I.e. I only want it to run on xscreen0.

I've been using Plasma 5.25.80 (package version 5.24.5.r11810.g1e498d074-1) from Manjaro's kde-unstable repository for a couple of days now. The behavior is still quite similar. After my screens wake up, the lock screen is visible only on one monitor, wallpapers are broken, desktop icons and panels are unresponsive and some applications appear on wrong screens. However, after a couple of minutes plasmashell is able to recover automatically --- correct wallpapers appear and panels start working. I don't see any crashes/coredumps in journalctl, but this assertion seems to be relevant:

plasmashell[1137]: ASSERT: "m_desktopViewForScreen.isEmpty()" in file /build/plasma-workspace/src/plasma-workspace/shell/shellcorona.cpp, line 795

CCing Fushan who may know what that means.

Hi I'm using the following Neon distro: 
~$ lsb_release -a
No LSB modules are available.
Distributor ID: Neon
Description:    KDE neon User - 5.24
Release:        20.04
Codename:       focal

Experiencing the same issues. After reboot , logging into x11 will give the black background and no right-click menu. logging out and selecting Wayland , then logging back in shows desktop and popup from Neon that Wayland is not supported. Logging back out, switching back to X11 seems to "fix" the issue after logging back in. 

Let me know if any other details will help to fix. But honestly a fix should be pushed via global update.

(In reply to lebr0nk from comment #177)
> Hi I'm using the following Neon distro: 
> ~$ lsb_release -a
> No LSB modules are available.
> Distributor ID: Neon
> Description:    KDE neon User - 5.24
> Release:        20.04
> Codename:       focal
> 
> Experiencing the same issues. After reboot , logging into x11 will give the
> black background and no right-click menu. logging out and selecting Wayland
> , then logging back in shows desktop and popup from Neon that Wayland is not
> supported. Logging back out, switching back to X11 seems to "fix" the issue
> after logging back in. 
> 
> Let me know if any other details will help to fix. But honestly a fix should
> be pushed via global update.

Do you have Plasma HiDPI enabled?

I think I managed to reproduce this when tweaking display settings (not just connecting the monitor).

I have two external monitors (1920x1080) and a laptop screen (1920x1200). Usually when the external displays are connected I set the laptop display to be disabled. I decided to set my laptop to be a duplicate of the left-most external display and noticed that when I did this, the right-most display lost its settings as per the description of the bug. Perhaps this could be used to help figure out what's going on with it.

*** Bug 454877 has been marked as a duplicate of this bug. ***

Could any people test https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1781 fixes your issue? Thanks in advance.

Hi there, I'm experiencing this as well, but it's a subtle variation on what others have reported. For me, this happens regardless of whether or not I have any external displays, and it occurs on *all* displays. It's similar to the zombie desktop reported by Agron. I have a video of it taking place here: https://www.youtube.com/watch?v=e4dmn-F0p98 I'll also attach the xprop output shown in that video, in case it's relevant.

I was hoping it'd be fixed in Plasma 5.25, but I just got the upgrade in Neon (great release, BTW; congrats!) and it's still occurring. Wayland does not work on this computer, so I can't use Wayland to get around it.

(In reply to Fushan Wen from comment #181)
> Could any people test
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1781 fixes
> your issue? Thanks in advance.

I am interested in testing this, but I am not sure how I would go about doing so in Neon. Patching system packages has always made me feel uneasy as a general thing, even having been on Linux for a very long time. :x However, I do have a BTRFS subvolume structure that makes it very low-risk to go absolutely ham on the system if I need to. Should I visit a specific Matrix channel for guidance on this?

Created attachment 149682 [details]
xprop output of the zombie desktop / black window

Here's that xprop output.

Sorry, I forgot to mention a couple things. My starting workspace is number #2; I use wmctrl to move over in a startup script that gets executed in autostart. But because of this, the zombie workspaces for me are actually 1, 3, and 4. And a `plasmashell --replace` does make it go away until the next boot.

(In reply to Fushan Wen from comment #181)
> Could any people test
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1781 fixes
> your issue? Thanks in advance.

I fear not, but I need to do more testing. I have installed the plasma-workspace hack. Did not yet test the Qt hack yet.

I feel like we are perhaps talking about 2 different issues here:
* one for Wayland
* one for Xorg

The fix present in comment  comment #181 seems to appply to Xorg only.

I feel like we are perhaps talking about 2 different issues here:
* one for Wayland
* one for Xorg

The fix present in  comment #181 seems to appply to Xorg only.

(In reply to Claus-Justus Heine from comment #184)
> (In reply to Fushan Wen from comment #181)
> > Could any people test
> > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1781 fixes
> > your issue? Thanks in advance.
> 
> I fear not, but I need to do more testing. I have installed the
> plasma-workspace hack. Did not yet test the Qt hack yet.

Ok, it seems that the plasma-workspace hack seems to improve things, but the qt-hack doesn't. Still this is just an observation from one time merging the Qt-Hack, and another time merging the Plasma-hack.

ATM, it seems that the plasma-hack ----- after a while, say 5 seconds ----- enable the Plasma-thing to "recover". At least it seems that I _may_ have  (sometimes???) usable screens on  each of my two monitors after either manually switching them off or waiting for the power save.

Still: there are many annoying things: windows are relocated to the other monitor, their size changes wildly. For that "primary display" feature: I do not understand: the control panel is always located on the "non-primary" monitor. Desktop icons are always located on the "primary" monitor. What is the reasoning behind? What exactly is meant by "primary monitor"?

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!

(In reply to Bug Janitor Service from comment #188)
> 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!

The bug is still ** not **  solved in 5.25.2. As for "needsinfo", would do you need? The last question was in comment #181 and the answer is "no". Also the patch from #181 has been incorporated into 5.25.2, AFAIK. So still after sleep or after manually switching monitors off (e.g. to save energy):

- occasionally on monitor goes black with unresponsive background
- windows are wildly relocated to other screens and resized (most often made very small)
- this strange and unintuitive "primary screen" switch in the system settings moves the "blackness" to the other screen. If the primary screen is black then making the other screen "primary" (what ever this means) recovers the responsive background on one screen and make the new "primary" screen black.

(In reply to Claus-Justus Heine from comment #189)
> (In reply to Bug Janitor Service from comment #188)
> > 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!
> 
> The bug is still ** not **  solved in 5.25.2. As for "needsinfo", would do
> you need? The last question was in comment #181 and the answer is "no". Also
> the patch from #181 has been incorporated into 5.25.2, AFAIK. So still after
> sleep or after manually switching monitors off (e.g. to save energy):
> 
> - occasionally on monitor goes black with unresponsive background
> - windows are wildly relocated to other screens and resized (most often made
> very small)
> - this strange and unintuitive "primary screen" switch in the system
> settings moves the "blackness" to the other screen. If the primary screen is
> black then making the other screen "primary" (what ever this means) recovers
> the responsive background on one screen and make the new "primary" screen
> black.

Hey, it's a bot message. You can change the bug status to confirmed to dismiss it. Do you have Qt scaling enabled? If not it's a new bug then.

Hello, just chiming in. I am also experiencing this issue after switching to a dual monitor layout, just as mikro and others reported. This is only happening on Wayland, and the only relevant log messages I see are several these ones, repeated over time, which I do not think are very relevant:

Jul 10 20:57:14 mostro plasmashell[27061]: [2022-07-10 20:57:14.840] [27081] (device_info_linux.cc:45): NumberOfDevices
Jul 10 20:57:17 mostro plasmashell[27061]: [2022-07-10 20:57:17.842] [27081] (device_info_linux.cc:45): NumberOfDevices
Jul 10 20:57:20 mostro plasmashell[27061]: [2022-07-10 20:57:20.845] [27081] (device_info_linux.cc:45): NumberOfDevices
Jul 10 20:57:23 mostro plasmashell[5843]: kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x5574fabb33e0)
Jul 10 20:57:23 mostro plasmashell[5843]: kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x5574fabb33e0)
Jul 10 20:57:23 mostro plasmashell[5843]: kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x5574fabb33e0)
Jul 10 20:57:23 mostro plasmashell[27061]: [2022-07-10 20:57:23.848] [27081] (device_info_linux.cc:45): NumberOfDevices


I personally don't have scaling enabled, and the X.org session works perfectly, only the Wayland one has these problems. Also, the workarounds mentioned above about deleting old configuration files didn't help at all. My plasma version is 5.25.2.

*** Bug 456711 has been marked as a duplicate of this bug. ***

Bug still present in X11 Plasma 5.25.3.

The bug is triggered depending 3 things:
1. Which monitor is set as the X Primary Display for X Screen (not sure if Wayland has a similar concept)
2. Which monitor wakes up first from sleep
3. Which monitor is configured to have Plasma Taskbar.

Reproducible: Always

Steps to reproduce:
1. Get 2 different monitor models that have different sleep/wakeup latency - in my case both are DisplayPort with different resolutions. My understanding is that DisplayPort sleep/wakeup is equivalent to disconnectintg/reconnecting cable.
2. Set the faster waking monitor as the Primary Display for X Screen - in my case I can do this with a tick-box in NVIDIA Settings application.
3. Place Plasma Taskbar onto the non-Primary monitor.
4. Leave system idle until both monitors go to sleep - in my case system itself doesn't sleep, only monitors and no screen locking.
5. Wake monitors up.

Actual Results:
Monitors wake up with Plasma missing - no taskbar, no desktop icons, no wallpaper, black screen, right click not working. Windows can be dragged between monitors. Can Alt-Tab between windows. No DrKonqi crash reports.
During first wakeup cycle KDE screens configuration seems to get reconfigured (depending on monitor wake-up order), and subsequent sleep/wake cycles could have different results and screen configuration (though taskbar always missing) depending on each pre-sleep state.

Expected Results:
Plasmashell not to disappear.

Workaround Fix:
Make the slower waking monitor as the Primary Display for the X Screen (in NVIDIA Settings tool), and have Plasma Taskbar residing on the faster waking screen. With this configuration every sleep/wakeup cycle works without any issues.

*** Bug 353722 has been marked as a duplicate of this bug. ***

Hi there. I actually have managed to fix my version of the issue, and even though it is different from what the rest of you are experiencing, what I discovered may provide a hint for fixing it, so I thought I would stop by and share my findings in hope that they will be helpful, at least for the Xorg case.

I had an idea that maybe the window that represents the Plasma desktop had somehow managed to get itself stuck on a specific workspace, and in order to confirm my findings, I used `xwininfo` instead of `xprop` on the black screen and received this output:

```
xwininfo: Window id: 0x979 (the root window) (has no name)

  Absolute upper-left X:  0
  Absolute upper-left Y:  0
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 1920
  Height: 2160
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +0+0  -0+0  -0-0  +0-0
  -geometry 1920x2160+0+0
```

That black screen is actually the root window! Plasma's desktop has a different output:

```
xwininfo: Window id: 0x2400013 "Desktop — Plasma"

  Absolute upper-left X:  0
  Absolute upper-left Y:  1080
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 1920
  Height: 1080
  Depth: 32
  Visual: 0x28a
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x2400012 (not installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +0+1080  -0+1080  -0-0  +0-0
  -geometry 1920x1080+0-0
```

And then, I decided to run `xprop` again, but this time, on the desktop.

```
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP
_NET_WM_DESKTOP(CARDINAL) = 1
WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0
_NET_WM_USER_TIME(CARDINAL) = 43952
_KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 44930
_NET_WM_STATE(ATOM) = _NET_WM_STATE_BELOW
_KDE_NET_WM_DESKTOP_FILE(UTF8_STRING) = "org.kde.plasmashell"
XdndAware(ATOM) = BITMAP
WM_NAME(STRING) = "Desktop"
_NET_WM_NAME(UTF8_STRING) = "Desktop — Plasma"
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x1, 0x0, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DESKTOP
_XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1
WM_CLIENT_LEADER(WINDOW): window id # 0x2400015
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: True
                window id # of group leader: 0x2400015
WM_CLIENT_MACHINE(STRING) = "Stealth"
_NET_WM_PID(CARDINAL) = 2116
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 37748756
WM_CLASS(STRING) = "plasmashell", "plasmashell"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                user specified location: 0, 1080
                user specified size: 1920 by 1080
                window gravity: Static
```

The second line is the one most of interest: the desktop is assigned to a specific virtual desktop. That's not supposed to happen! I created a KWin rule that takes windows of class plasmashell and type desktop, and forces them to be visible on all desktops. That caused my version of this issue to be resolved!

So what I can state with almost certainty is that the black window that people can't interact with is the root window. The desktop is supposed to cover up that window while being beneath everything else, and for some reason, that is not happening. It is possible that the state of the window representing the Plasma desktop is being mangled in such a way that the window manager is representing it correctly according to its internal state, but incorrectly according to user expectations.

I have a multi monitor setup as well. The desktop is represented by a different window on each monitor; `xwininfo` shows different ids for clicking the desktop on each one. And `wmctrl` actually shows the same thing, as shown here. I threw in the G switch in order to get the geometry information; both position and size.

```
❯ wmctrl -lG
0x04a0000c  0 40   1080 1880 1080 Stealth 353975 – Black screen on second display (no wallpaper, can't get a context menu on right-click) — Mozilla Firefox
0x05a00003 -1 0    0    1920 1080 Stealth Spotify
0x03400014  0 40   1080 1880 1080 Stealth Inbox (30 unread) — Evolution
0x07e00003 -1 0    0    1920 1080 Stealth Ferdium - Discord - Discord
0x06a00002  0 40   1080 1880 1080 Stealth Joplin
0x04200013 -1 0    1080 1920 1080 Stealth Desktop — Plasma
0x04200019 -1 0    0    1920 1080 Stealth Desktop — Plasma
0x04200035 -1 0    1080 40   1080 Stealth Plasma
0x09600013  1 842  1117 1078 1043 Stealth black-screen-xwininfo.txt - CudaText
0x09800007  1 40   1117 802  506  Stealth hOI!!! im termmie!!! — Konsole
```

So I think everyone experiencing this issue on Xorg will be able to provide more information by using `wmctrl -lG`. What I suspect might be happening, for those experiencing this on a second monitor rather than my weird case, is that the desktop windows are getting placed in the same location somehow. But only one of you will be able to confirm that. And if that's the case, hopefully that's a clue to fixing this bug.

I hope this comment proves helpful. :)

People who are affected: can you open your ~/.config/plasmashellrc file and paste everything under [ScreenConnectors]?

I'm starting to suspect that basically all of these issues are caused by Bug 450068.

2 x identical monitors both LG 4k - one connected via USB-C the second via HDMI.

[ScreenConnectors]
0=
1=DP-2
2=:0.0

The behavior after 5.25.4 - now after screen lock is woken up - both monitors show same info (mirror mode) - after fiddling (a lot) can convince it back to 2 monitors - then it happens again. The above is the state reflecting mirror version. If its helpful I can try get dual monitors working again and then resend if its any different.

I know there's a bug in the way ScreenConnectors works because of how the screens are identified. Screen names aren't unique as they're identified by xrandr output name. My ScreenConnectors looks like this:

[ScreenConnectors]
0=DVI-I-1
1=HDMI-0
2=HDMI-1
3=DVI-D-0

But my system has two different displays both called DVI-I-1. This is because I have 6 displays across 2 GPUs. In my case I only want plasma to run on the 1st GPU (as xscreen 0), but when DVI-I-1 on the second GPU (on xscreen 1) connects Plasma sees this and runs a shell on that one. This prevents it from running a shell on the screen0 one.

ScreenConnectors should include either a GPU identifier or xscreen number to fix this issue.

I have fixed this myself with a patch that adds a new "IgnoredScreens" section to plasmashellrc and I get plasma to ignore any monitor that has a serial number that's in that list. This is slightly annoying because each time a new version of plasma-workspace comes out I have to redo my patch.

If I use kcm to split the displays into 2 (left and right) plasmashell the plasmashellrc doesn't change - and it crashes shortly after hitting apply and backgrounds go black and its back in mirror mode again.

Both displays are labelled the same in the settings as mentioned above which seems odd obviously.

On other hand my laptop with a single USB (DP) monitor works fine - of course these are always distinguishable so perhaps makes sense.

Today faced same issue on laptop, without any additional monitors ever connected.
 ~/.config/plasmashellrc doesn't contain [ScreenConnectors] section.
Arch linux , nvidia 515.65.01-2 , plasma-desktop 5.25.4-1 , xorg-server 21.1.4-1
Please tell if there is any information I could provide to help investigation.

(In reply to mikro from comment #124)
> I am on Fedora 35 with KDE 5.24.2
> I have two monitors, connected to the same Graphic adapter (Radeon RX 580)
> and they are utilizing one HDMI and one Display Port connection.
> I disconnect (power off) my primary monitor and the other one remains as it
> was.
> When I power on again my primary monitor, all my monitors are as before
> except:
> 
> - No wallpapers, only black background on both but at some point the
> wallpaper on the primary monitor will be visible again
> - My secondary monitor (the one that I didn't power off) does not accept
> right clicks on the desktop surface
> - My primary monitor accepts right clicks on the desktop surface and I can
> open the "Configure Desktop and Wallpaper" window. But when I do that, opens
> two (2) to four (4)  Configure Desktop and Wallpaper windows, one above the
> other. While these are opened I can see for a split second the wallpaper of
> my primary monitor disappearing and reappearing.
> 
> One way to restore everything, as they were is:
> 
> Open the Display settings, disable and then enable again, the secondary
> monitor. 
> Then, everything will be fine, but while I can now open the "Configure
> Desktop and Wallaper" window on my secondary monitor without any issue, if I
> try to open it on my primary monitor, immediately I am back to as if I had
> disconnected the primary monitor situation, which means:
> 
> - No wallpapers, only black background on both but at some point the
> wallpaper on the primary monitor will be visible again
> - My secondary monitor (the one that I didn't power off) does not accept
> right clicks on the desktop surface
> - My primary monitor accepts right clicks on the desktop surface and I can
> open the "Configure Desktop and Wallpaper" window. But when I do that, opens
> two (2) to four (4)  Configure Desktop and Wallpaper windows, one above the
> other. While these are opened I can see for a split second the wallpaper of
> my primary monitor disappearing and reappearing.
>   
> The only real solution is to log off and log on again to my Desktop

The bug is still here. I have upgraded my system to Fedora 36: 

KDE plasma version 5.25.4
KDE Framework: 5.96.0
QT version: 5.15.5

and I am using exclusively Wayland.

The manifestation is more or less similar with my original post but not exactly the same. 
I am not going to provide an exact description because I don't really see any effort from the KDE team to address this bug in the first place.
In my experience, the multi monitor plasma issues is a long standing problem. 
At some point someone from KDE developer team must be tasked to resolve it and I hope that day will come soon enough!

Indeed it is quite disheartening that a bug of this obviously very high importance sees no feedback. Neither this or 450068 have been assigned - so that means no-one is working on it.

Really hate to switch back to gnome but best I can tell at least multi monitor set up works there.

@Nate - can you please provide a time frame for when this awful bug might be (a) worked on and (b) fixed?

Can anyone confirm they can still reproduce this bug without any DP ports connected? I only have HDMI port connected and currently I can't reproduce black screen on both X11 and Wayland.

I suspect all the issues here are 99% the same as Bug 450068, which indeed hits DisplayPort users harder than HDMI users, since it seems like the screen connector IDs are much more volatile for DisplayPort monitors, especially when used with DisplayPort docks.

I asked people to post their ScreenConnectors data to test this theory, and so far the data people have reported is tending to confirm it.

The good news is that Plasma developers have acknowledged the fragility of the current approach of mapping desktops and panels to screen connector IDs and are working ona fundamentally different data source, which should automatically solve most of the bugs. It's currently targeted for Plasma 5.26, but could end up pushed to 5.27.

*** This bug has been marked as a duplicate of bug 450068 ***

(In reply to Nate Graham from comment #204)
> I suspect all the issues here are 99% the same as Bug 450068, which indeed
> hits DisplayPort users harder than HDMI users, since it seems like the
> screen connector IDs are much more volatile for DisplayPort monitors,
> especially when used with DisplayPort docks.
> 
> I asked people to post their ScreenConnectors data to test this theory, and
> so far the data people have reported is tending to confirm it.
> 
> The good news is that Plasma developers have acknowledged the fragility of
> the current approach of mapping desktops and panels to screen connector IDs
> and are working ona fundamentally different data source, which should
> automatically solve most of the bugs. It's currently targeted for Plasma
> 5.26, but could end up pushed to 5.27.

Yeah okay but is there a workaround currently? Because just can't work. Cannot open anything, kRunner doesn't open anything, no taskbar, no right click. Switching to one screen doesn't always make the job, sometimes it just freeze everything

A workaround that works for me is:

1.) Go to the system settings, screen/display configuration

2.) In the diagram which shows the relative position of your two screens, move slightly the position of the screen that does not work correctly.

3.) Click on  "Apply"

4.) In the following dialogue, you are asked if you want to save the new settings. Do NOT save them.

Now, the problem is solved (until the next restart).

(In reply to Lukas Sommer from comment #207)
> A workaround that works for me is:
> 
> 1.) Go to the system settings, screen/display configuration
> 
> 2.) In the diagram which shows the relative position of your two screens,
> move slightly the position of the screen that does not work correctly.
> 
> 3.) Click on  "Apply"
> 
> 4.) In the following dialogue, you are asked if you want to save the new
> settings. Do NOT save them.
> 
> Now, the problem is solved (until the next restart).

How to perform step one on this situation?

Yeah I was used to do that to correct minor graphic glitches without losing my perfect configuration. But now the problem is bigger than that and I just can't open apps. Even when I manage to open one, it's out of reach, impossible to interact with it or retreive it in screen. It's just displayed in the switch app menu and thats all. So this trick will not save me this time

I found a work around that works fine - i installed gnome (yes I know) and if kde every gets to a usable state can always use gdm to launch plasma. gdm is native wayland and seems more stable than sddm which also helps.

not ideal for sure but based on @nate's indicated time frames, sounds like this won't be fixed until 2023, which is a little too long for me.
I'll keep an eye out but for now plasma is just not usable.

(In reply to gene c from comment #209)
> I found a work around that works fine - i installed gnome (yes I know) and
> if kde every gets to a usable state can always use gdm to launch plasma. gdm
> is native wayland and seems more stable than sddm which also helps.
> 
> not ideal for sure but based on @nate's indicated time frames, sounds like
> this won't be fixed until 2023, which is a little too long for me.
> I'll keep an eye out but for now plasma is just not usable.

It's foolish to think that already worked fine till now. They should regress the stable version to one before that didn't had this bug. It shouldn't be considered stable to have such problem

Anyway, people often asked me why I've installed such ton of WM. And it's exactly for that, to switch in case something went wrong. So yeah, I use GDE when I can't deal anymore with KDE. About display manager, I already use GDM since long. On this computer I even never used SDDM I think. Thanks for the tip, even if it's sad

FWIW, on my machine, I'd say this bug has significantly regressed.  I used to only very rarely have black screen issues.  Now they are common.  It is very disappointing that this bug has been treated as such a low-priority problem - when it is quite remarkably bad.  I've been using KDE for almost 20 years but right now this is right on the edge of driving me to Gnome as well.

(In reply to Greg White from comment #211)
> FWIW, on my machine, I'd say this bug has significantly regressed.  I used
> to only very rarely have black screen issues.  Now they are common.  It is
> very disappointing that this bug has been treated as such a low-priority
> problem - when it is quite remarkably bad.  I've been using KDE for almost
> 20 years but right now this is right on the edge of driving me to Gnome as
> well.

Personally I had multiple kind of black screen issues, along with other kind of bug who were as bothering. Some had been corrected, some come sometimes. But this one, it's pretty new, less than a week, and it's the worst black screen kind. It literally paralyze me and drive me crazy. WayLand is not something easy to manipulate

(In reply to Greg White from comment #211)
> FWIW, on my machine, I'd say this bug has significantly regressed.  I used
> to only very rarely have black screen issues.  Now they are common.  It is
> very disappointing that this bug has been treated as such a low-priority
> problem - when it is quite remarkably bad.  I've been using KDE for almost
> 20 years but right now this is right on the edge of driving me to Gnome as
> well.

I'm in this boat as well. I love KDE and have been affected by this issue for several months. It makes me sad that this is potentially being kicked down the road to 2023. Can this bug receive some attention soon? If not, I also will have to ditch KDE.

(In reply to Fushan Wen from comment #203)
> Can anyone confirm they can still reproduce this bug without any DP ports
> connected? I only have HDMI port connected and currently I can't reproduce
> black screen on both X11 and Wayland.

HDMI here. Intel Iris Xe video. Reproducible on X11. It's not consistent, however. Sometimes there are no issues, and randomly the black screen bug will occur.

The issue is more common with DisplayPort monitors because DisplayPort connector IDs are extremely volatile, more so than HDMI connector IDs. But HDMI connector IDs aren't immune to it, so the issues happen there too, just less frequently.

(In reply to Nate Graham from comment #204)
> I suspect all the issues here are 99% the same as Bug 450068, which indeed
> hits DisplayPort users harder than HDMI users, since it seems like the
> screen connector IDs are much more volatile for DisplayPort monitors,
> especially when used with DisplayPort docks.
> 
> I asked people to post their ScreenConnectors data to test this theory, and
> so far the data people have reported is tending to confirm it.
> 
> The good news is that Plasma developers have acknowledged the fragility of
> the current approach of mapping desktops and panels to screen connector IDs
> and are working ona fundamentally different data source, which should
> automatically solve most of the bugs. It's currently targeted for Plasma
> 5.26, but could end up pushed to 5.27.

So this means that the plasma until then will not support multi-monitor configurations? Multi-monitor support got broken since approximately start of this year (that _this_ bug started in 2015 is just fake). This is very unfortunate. At this point it is also for me probably time to say goodbye to kde.

No flames intended, of course, I known that this is spare-time work mostly. So if this issue cannot be solved earlier then so be it. Still I will see if I use something else in the meantime.

Thanks to the kde/plasma developers for all their effort! I probably check back later.

Plasma fully supports multiple screens, it's just that this design error causes that support to be buggy for certain combinations of screens, graphics cards, connection methods, kernels, physical positioning, whether you're using Wayland or X11, and so on. The number of variables that go into it is quite enormous. This is why it works perfectly for some people, and terribly for others.

It's true that there was a significant regression surrounding multi-monitor support earlier this year, but it was a result of us doubling down on the existing approach and trying our best to make it work more robustly. That it has the opposite effect cemented our resolve to replace the current buggy screen connector ID based system to something more reliable. It's being planned out now and I do have high hopes for it to be shipped with Plasma 5.26.

If the status quo is so bad for you that you have to use another DE in the meantime, that's understandable.

Before you all move to a different DE for the time being, can we get some `wmctrl -lG` outputs from people being affected by this issue, along with your monitor arrangements? I believe I have made a strong case for the possibility that the desktop windows are being misplaced somehow, and the black screen is the root window. If we can get confirmation or deconfirmation on whether or not this is happening to you all, it will help the developers working on this issue solve it.

Ctrl+Alt+T should be the default shortcut to open a new Konsole window, if you find yourself unable to open a terminal any other way.

0x01a00011 -1 0    0    2160 3840 lively Desktop — Plasma
0x01a00017 -1 2160 0    2160 3840 lively Desktop — Plasma
0x01a00035 -1 0    0    2160 56   lively Plasma
0x01a00057 -1 2160 0    2160 56   lively Plasma
0x04c00051  0 0    56   2160 3784 lively weco-server – celery.py
0x00400003  0 0    56   2160 3784 lively New Tab - Brave
0x00400005  0 0    56   2160 3784 lively [plasmashell] [Bug 353975] Black screen on second display (no wallpaper, can't get a context menu on right-click) - gwhite@kupulau.com - Kupulau Mail - Brave
0x03200007  0 0    56   2159 3783 lively weco-server : fish — Yakuake

AMDGPU on a radeon rx550.  tzwo 4K monitors rotated 90 degrees.  Left monitor is HDMI; right is DP.  

Last failure mode was the HDMI connected monitor going black and staying that way.  I'm personally not convinced that HDMI is any more stable, FWIW.

(In reply to Trent M from comment #218)

I tried running this in gnome in a gnome-terminal and got no output - sorry.

[ScreenConnectors]
0=DP-4
1=DP-2-1
10=eDP-1
11=DP-6
2=DP-2-2
3=:0.0
4=DP-1
5=DP-8
6=DP-7
7=DP-2
8=DP-2-1-6
9=DP-2-1-5

Currently HDMI through Thunrderbolt(DP-6 above) is main screen horizontal and secondary screen turned 90 degrees starting from 0 0 is a DP connect screen also on Thunderbolt dock(DP-4 above).

 I get black screen or half desktop walpaper on the main screen when I disconnect and reconnect the Thunderbolt dock.

Forgot to add the output wmctrl output:

wmctrl -lG
0x01800003  0 3840 511  1440 1507 hssl-MACHC-WAX9 Spotify

does wmctrl need to be run once or on each monitor?

Looks like it's X11 tool, if you are running like me on Wayland then there would be only Xwayland windows, I suppose

(In reply to H.G.Blob from comment #224)
> Looks like it's X11 tool, if you are running like me on Wayland then there
> would be only Xwayland windows, I suppose

Ok thanks -  all wayland here too.

That's my bad, I should have been more specific when I asked for the wmctrl output. This will only be relevant if you are running Plasma on X11. Output from other DEs won't be helpful because this bug is only relevant for Plasma, though it could offer insight to what other X11 DEs are doing with their desktop windows for multi-monitor. And wmctrl won't be helpful on Wayland. I'm surprised it works on Wayland *at all*, but I suppose it makes sense that it only outputs Xwayland windows.

And something else I should have been more specific about is that `wmctrl -lG` needs to be run while the black screen situation is occurring, because I know it is sporadic for some of you. The idea is that we want to see where the desktop windows are located, and if they're in the wrong place, we want to catch that.

So Greg's output is the one thus far that's relevant to the X11 case. Greg, was this created during a situation where the black screen issue was happening? Because if so, we've deconfirmed the relevance of desktop window placement: the desktop windows and plasma windows are appearing exactly where they should be: 0, 0 for one monitor and 2160, 0 for the other. However, if this was created when the black screen issue *wasn't* happening, then you have useful data in the sense that you know what the output *should* look like when things are working right.

(In reply to Trent M from comment #218)
> Before you all move to a different DE for the time being, can we get some
> `wmctrl -lG` outputs from people being affected by this issue, along with
> your monitor arrangements? I believe I have made a strong case for the
> possibility that the desktop windows are being misplaced somehow, and the
> black screen is the root window. If we can get confirmation or
> deconfirmation on whether or not this is happening to you all, it will help
> the developers working on this issue solve it.

So this is

kde-frameworks/plasma-5.97.0
kde-plasma/plasma-workspace-5.25.4

Both monitors via HDMI, the left rotated by 90 deg, running X11 on

Advanced Micro Devices, Inc. [AMD/ATI] Picasso/Raven 2 [Radeon Vega Series / Radeon Vega Mobile Series] (rev c8)

Currently the right screen (HDMI-A-0) is black. I can "make the other screen black" when tagging the left one (HDMI-A-1) as "primary" (what does this mean??) display. Then the left screen wents black, the button pane is relocated to the left screen, and the desktop icons are moved to the right screen)

Thank you for your work!

xrandr: (showing only the active resolution):
Screen 0: minimum 320 x 200, current 6000 x 3840, maximum 16384 x 16384
HDMI-A-0 connected primary 3840x2160+2160+721 (normal left inverted right x axis y axis) 596mm x 335mm
   3840x2160     60.00*+  60.00    59.94    30.00    25.00    24.00    29.97    23.98    24.00  
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
HDMI-A-1 connected 2160x3840+0+0 left (normal left inverted right x axis y axis) 596mm x 335mm

Output of wmctrl:
claus@anaxagoras ~ $ wmctrl -lG
0x01600011 -1 2160 721  3840 2160 anaxagoras Arbeitsfläche — Plasma
0x01600031 -1 2160 2785 3840 96   anaxagoras Plasma
0x07800007  9 2593 774  2954 2011 anaxagoras root@radxa-zero : root@radxa-zero: ~ — Konsole
0x07e00007  7 3365 843  2160 1893 anaxagoras selectize : claus@anaxagoras:/var/www/localhost/htdocs/nextcloud-git/apps/cafevdb/3rdparty/selectize — Konsole
0x08200007  4 240  163  1920 1750 anaxagoras ~ : claus@anaxagoras:~ — Konsole
0x07a0007a  0 0    1504 2160 2000 anaxagoras Posteingang - himself@claus-justus-heine.de - Mozilla Thunderbird
0x090000aa  7 4144 774  1856 1939 anaxagoras select-utils.js
0x090014ea  7 2160 774  1920 1939 anaxagoras email.js
0x0440002c  7 0    836  2160 1555 anaxagoras CAFeVDB - Nextcloud - Mozilla Firefox
0x0440004f  0 0    38   2160 1712 anaxagoras alternatives to plasma kde - Google Suche - Mozilla Firefox
0x044001d9  7 3569 774  2160 1838 anaxagoras Entwicklerwerkzeuge - CAFeVDB - Nextcloud - https://anaxagoras.home.claus-justus-heine.de/nextcloud-git/index.php/apps/cafevdb/
0x04400831  0 20   73   700  720  anaxagoras Visitenkarte von Bock, Ingrid - C@MPUS - Universität Stuttgart - Mozilla Firefox
0x04800007  0 0    556  2160 931  anaxagoras ~ : claus@anaxagoras:~ — Konsole
0x04a00007  0 0    247  2160 1335 anaxagoras logreader : claus@anaxagoras:/var/www/localhost/htdocs/nextcloud-git-next/apps/logreader — Konsole
0x08000007  0 0    58   2160 1592 anaxagoras ~ : claus@anaxagoras:~ — Konsole
0x04400d65  9 0    849  2160 1712 anaxagoras external graphics card case – Google Suche - Mozilla Firefox
0x04401033  0 0    918  2160 1712 anaxagoras Confluence | Der Remote-freundliche Arbeitsbereich für dein Team - Mozilla Firefox
0x07600033  0 0    1113 2160 1503 anaxagoras LDAP - cn=Lenz\2C Britta,ou=People,dc=mathematik,dc=uni-stuttgart,dc=de - @mathematik - Apache Directory Studio 
0x08c00007  0 0    53   1765 1294 anaxagoras Lautstärkeregler
0x09200006  0 0    1888 2160 1552 anaxagoras Bluetooth  — Systemeinstellungen
0x09400007  9 0    1132 2160 931  anaxagoras root@localhost : root@anaxagoras:/etc — Konsole
0x0160264f -1 0    0    2160 3840 anaxagoras Arbeitsfläche — Plasma
0x0280003a  9 2633 1008 2606 1711 anaxagoras Nextcloud-Einstellungen
0x08600007  0 3000 774  2160 2011 anaxagoras ~ : claus@anaxagoras:~ — Konsole

Kind of obvious question:  since gnome is working extremely well, and is open source, have kde devs looked at gnome code to see what they do to handle multiple monitors with a view to potentially follow their methodology (with appropriate attribution etc)? 

Assuming of course, as some may have suggested, that there is an algorithmic weakness rather than a sound approach that is just buggy in plasma.  But if the kde approach is flawed, then gnome may help light a path forward?

Folks - bit off-topic but a small suggestion - you may want  to remove any potentially sensitive info before pasting it here.

(In reply to gene c from comment #228)
> Kind of obvious question:  since gnome is working extremely well, and is
> open source, have kde devs looked at gnome code to see what they do to
> handle multiple monitors with a view to potentially follow their methodology
> (with appropriate attribution etc)? 

It's not terribly relevant; the surrounding infrastructure and usage model is just completely different. If we followed the GNOME approach, we would have to lose customizable desktops, customizable panels, desktop widgets, desktop icons, and so on, because the GNOME approach works because it doesn't have to deal with the complexity of those Plasma features.

(In reply to gene c from comment #229)
> Folks - bit off-topic but a small suggestion - you may want  to remove any
> potentially sensitive info before pasting it here.

<offtopic>
Oops. BTW, is it possible to edit comments after posting them? Gitlab as well as Github support that in their issue tracker.
</offtopic>

(In reply to Nate Graham from comment #230)
> (In reply to gene c from comment #228)

> ...
> have to lose customizable desktops, customizable panels, desktop widgets,
> desktop icons, and so on...

Hiya Nate - yeh sorry I wasn't terribly clear, let me try expand a bit.

In above I was simply referring to their method of identification / tagging of monitors in multi display setting and not the DE philosophy around what can be customized.

I've not gone over code for either DE, so I could well be missing something - but the problems here seem at least partly related to correctly identifying and tagging monitors, which I would not have guessed would impact customization. But hey, what do I know ... :)

If indeed some customization were lost, say different backgrounds on different monitors or whatever, but things otherwise work - yes that would 100% be preferable to more flexible but not working. But absent detailed knowledge of the code,  I would have guessed that customizing and display tagging are largely mutually orthogonal.

Anyway, thanks.

I face a separate issue caused by Plasma identifying monitors by their xrandr connector name. Plasma seems to assume that these are unique in a system but they aren't. In my case I have 6 monitors across 2 GPUs and each of them has a DVI-I-1 monitor. Because ScreenConnectors uses this name it causes issues of it starting a plasma shell on the wrong monitor. I fixed this by modifying /shell/screenpool.cpp to get it to ignore monitors by serial number. This was the only property on the QScreen instance that seemed to be unique. This solution works well, though each time a new release comes out I need to repatch the source (I run Gentoo Linux).

Any solution that is looking to identifying monitors needs to make sure the identifier is consistent across reboots and is unique. I know the issue in this bug is about display name consistency, but can we please also consider the uniqueness problem in the solution?

For reference there are more details of my issue here, as well as a link to the patch that fixes it.
https://invent.kde.org/plasma/plasma-workspace/-/issues/51
Thanks,
Allistar.

I have a main monitor (1920x1080) the one in the laptop). And an external monitor, connected by HDMI output via a HDMI-to-VGA adapter (1280x1024). The external monitor is on the left in the screen layout, while the main monitor is on the right in the screen layout.

Result after starting the laptop, during the bug is present:

lukas@lukas-laptop:~$ wmctrl -lG
0x02400017 -1 1280 0    1920 1080 lukas-laptop Arbeitsfläche — Plasma
0x0240001d -1 1920 0    1280 1024 lukas-laptop Arbeitsfläche — Plasma
0x02400045 -1 1280 1036 1920 44   lukas-laptop Plasma
0x0240005d -1 0    992  1280 32   lukas-laptop Plasma
0x05000007  0 1546 154  1280 695  lukas-laptop ~ : bash — Konsole

And after applying the workaround described at https://bugs.kde.org/show_bug.cgi?id=353975#c207 :

lukas@lukas-laptop:~$ wmctrl -lG
0x02400017 -1 1280 0    1920 1080 lukas-laptop Arbeitsfläche — Plasma
0x0240001d -1 0    0    1280 1024 lukas-laptop Arbeitsfläche — Plasma
0x02400045 -1 1280 1036 1920 44   lukas-laptop Plasma
0x0240005d -1 0    992  1280 32   lukas-laptop Plasma
0x05000007  0 1546 154  1280 695  lukas-laptop ~ : bash — Konsole

*** Bug 458223 has been marked as a duplicate of this bug. ***

Gene C is right; be careful that your window titles aren't showing any sensitive information when you share your results. It is my bad for not cautioning against that as well. I apologize.

Lukas, your test case proves that my hypothesis is correct in some situations. It does not appear to be the case for all situations, but at least I was not completely off base.

See here, when you are first experiencing the error:

> 0x02400017 -1 1280 0    1920 1080 lukas-laptop Arbeitsfläche — Plasma
> 0x0240001d -1 1920 0    1280 1024 lukas-laptop Arbeitsfläche — Plasma

These are the desktop windows. The third through seventh columns represent x position, y position, width, and height, in that order. 

Now see the same windows when you are not having the problem:

> 0x02400017 -1 1280 0    1920 1080 lukas-laptop Arbeitsfläche — Plasma
> 0x0240001d -1 0    0    1280 1024 lukas-laptop Arbeitsfläche — Plasma

One of your monitors' desktop windows stays in the right place, the one at 1280,0. That's your right-side monitor. However, the desktop window that should be covering your left monitor wanders off to 1920,0 in the case where you are experiencing the black-screen bug, leaving the completely useless root window exposed beneath it. And interestingly, it causes the two windows to overlap *partially*, not completely. Lukas, on your right monitor, do you sometimes see the wallpapers partially overlapped when this problem is occurring?

The fact that your monitors have different sizes exposes a pretty interesting facet of this problem. During the case where the black screen monitor bug is occurring, the desktop windows don't seem to know which of them is the right-side monitor. The fact that the window for your 1280x1024 monitor goes to 1920,0 suggests that it thinks it's supposed to be on the right side for some period of time, and it just never gets corrected.

Because your monitors are different sizes, you could actually fix this with devilspie2 or a KWin script: you would check the sizes of the windows of class plasmashell and type desktop. Whichever one is 1280x1024, you move it to 0,0. Whichever one is 1920x1080, you move it to 1280,0. You would not be able to use KWin's window rules to fix this though, because it doesn't let you match windows on their sizes. For folks with monitors that are the same size though, they're out of luck for a workaround; the windows seem to be identical otherwise. They don't expose any differentiating information via xprop, presumably because the windows are supposed to simply do the right thing by themselves, and they're unfortunately not at the moment.

> Lukas, on your right monitor, do you sometimes see the wallpapers partially overlapped when this problem is occurring?

Yes.

(In reply to Trent M from comment #236)

For whatever is worth, I see the same issue on _Wayland_ with 2 monitors where one is rotated 90o. I can see the main screen partially overlapped, but when I click on that artefact it goes away.

*** Bug 413326 has been marked as a duplicate of this bug. ***

*** Bug 353722 has been marked as a duplicate of this bug. ***

*** Bug 459080 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2125

Git commit 9c7ac7061c5c85d63875eaee70793ba04334c1d0 by Marco Martin, on behalf of Fushan Wen.
Committed on 16/09/2022 at 14:34.
Pushed by mart into branch 'master'.

Revert "Revert "Prevent panel going out of screen boundaries""

This reverts commit 17774bc4c673294a7c8a6e80660d83cce1ba8891

There is still a known culprit (duplicate display names) so the hack shouldn't be reverted.
Related: bug 438114

M  +3    -0    shell/panelview.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/9c7ac7061c5c85d63875eaee70793ba04334c1d0

Git commit df793b9bbd874776ad65808893717517c1c0e5ec by Fushan Wen.
Committed on 16/09/2022 at 14:35.
Pushed by fusionfuture into branch 'Plasma/5.26'.

Revert "Revert "Prevent panel going out of screen boundaries""

This reverts commit 17774bc4c673294a7c8a6e80660d83cce1ba8891

There is still a known culprit (duplicate display names) so the hack shouldn't be reverted.
Related: bug 438114


(cherry picked from commit 9c7ac7061c5c85d63875eaee70793ba04334c1d0)

M  +3    -0    shell/panelview.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/df793b9bbd874776ad65808893717517c1c0e5ec

I have 2 installations of opensuse tumblesweed on the same PC:

Main OS:
I dont know if this is relevant at all
But on my main OS (which i use all the time) upon booting up, i get a grey background with three small green squares on it
that all cycles alone a few times, then i wait about 10 seconds then the SDDM login screen appears on all monitors
My Primary monitor often has a black screen on it when i boot up (no wallpaper)

Second OS:
Upon bootup - i get the usual normal expected Linux Output Text before the SDDM screen comes on all monitors
No issues at all with the primary monitor desktop background wallpaper

Does the difference between the 2 OS's with regards to the "grey screen with 3 small squares on it" on the first OS but not the second OS have any relevance ? considering that second OS does not have the black screen bug ?


The 2 OS's are on different SSDs


Monitors & their Connections:


1. SONY 32" - HDMI cable to AMD/ATI Radeon video card - Main PC Desktop monitor - PRIMARY
2. VA905 10" - DVI cable to AMD/ATI Radeon video card - Second Monitor
3. SONY 40" - HDMI cable to Motherboard (i915 driver) - Intel HD4000 GPU Motherboard Chip

AMD/ATI = Radeon HD 7850 (7000 Series) PCI-E Video Card

KDE Display Set up is as above from left to right hand side


Main OS:

[ScreenConnectors]
0=HDMI-A-3
1=VGA-1-1
2=HDMI-1-1
3=VGA-1
4=HDMI-A-1
5=HDMI-A-2
6=HDMI-1-2

[Updates]
performed=/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/containmentactions_middlebutton.js,/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/digitalclock_rename_timezonedisplay_key.js,/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/klipper_clear_config.js,/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/maintain_existing_desktop_icon_sizes.js,/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/move_desktop_layout_config.js,/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/no_middle_click_paste_on_panels.js,/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/systemloadviewer_systemmonitor.js,/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/unlock_widgets.js



Second OS:

[ScreenConnectors]
0=HDMI-A-3
1=VGA-1
2=HDMI-A-1
3=HDMI-A-2

[Updates]
performed=/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/containmentactions_middlebutton.js,/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/digitalclock_rename_timezonedisplay_key.js,/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/klipper_clear_config.js,/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/maintain_existing_desktop_icon_sizes.js,/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/move_desktop_layout_config.js,/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/systemloadviewer_systemmonitor.js,/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/unlock_widgets.js,/usr/share/plasma/shells/org.kde.plasma.desktop/contents/updates/no_middle_click_paste_on_panels.js

Git commit 579075f53a49c4e248b5d83a43ee83a903b06272 by Fushan Wen.
Committed on 21/09/2022 at 06:54.
Pushed by fusionfuture into branch 'Plasma/5.24'.

Revert "Revert "Prevent panel going out of screen boundaries""

This reverts commit 17774bc4c673294a7c8a6e80660d83cce1ba8891

There is still a known culprit (duplicate display names) so the hack shouldn't be reverted.
Related: bug 438114


(cherry picked from commit 9c7ac7061c5c85d63875eaee70793ba04334c1d0)

M  +3    -0    shell/panelview.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/579075f53a49c4e248b5d83a43ee83a903b06272

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2186

(In reply to Bug Janitor Service from comment #247)
> A possibly relevant merge request was started @
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2186

Could people seeing the bug try this patch to see if the bug is ""mitigated"?

I have no problem testing it, but I'm not sure what I need to do. I suppose I need to recompile something?
I'm currently on neon testing, so shouldn't be too far from the commit.

(In reply to H.G.Blob from comment #249)
> I have no problem testing it, but I'm not sure what I need to do. I suppose
> I need to recompile something?
> I'm currently on neon testing, so shouldn't be too far from the commit.

I am not familiar with deb packaging so I can't really help here. The patch will not be shipped until tested, but unfortunately I can't reproduce the bug.

(In reply to Fushan Wen from comment #248)
> (In reply to Bug Janitor Service from comment #247)
> > A possibly relevant merge request was started @
> > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2186
> 
> Could people seeing the bug try this patch to see if the bug is ""mitigated"?

Tried with the patch applied to v5.26 Plasma on Gentoo.
Issue remains.
After waking two DisplayPort monitors from sleep, one of them has black screen with no wallpaper, no icons, no context menu.

(In reply to Alexey Chernyak from comment #251)
> (In reply to Fushan Wen from comment #248)
> > (In reply to Bug Janitor Service from comment #247)
> > > A possibly relevant merge request was started @
> > > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2186
> > 
> > Could people seeing the bug try this patch to see if the bug is ""mitigated"?
> 
> Tried with the patch applied to v5.26 Plasma on Gentoo.
> Issue remains.
> After waking two DisplayPort monitors from sleep, one of them has black
> screen with no wallpaper, no icons, no context menu.

Thank you for testing!

Yes, the issue will continue to recur until we fix Bug 450068. It's just not really possible to fix 100% with the current system. That's why we're re-doing it to make this kind of bug possible to actually fix!

*** Bug 464157 has been marked as a duplicate of this bug. ***

*** Bug 464414 has been marked as a duplicate of this bug. ***

PLEASE NOTE!

If you are using Plasma 5.27 or later and you believe you are still experiencing the bug, please file a new bug report for it, rather than commenting in here. This is because in 5.27 and beyond, the code has changed significantly enough that new manifestations of the same issue are likely to have different root causes.

Thanks everyone!