It started with Plasma 5.8.2. I used to have separate wallpaper and the "toolbox" icon disabled. Now everytime when I connect my monitor (DP1) I see default plasma wallpaper and toolbox icon enabled.
can you attach ~/.config/plasmashellrc and ~/.config/plasma-org.kde.plasma.desktop-appletsrc ?
Created attachment 101922 [details] .config/plasmashellrc
Created attachment 101923 [details] ~/.config/plasma-org.kde.plasma.desktop-appletsrc
Attached, but I just re-set wallpaper and hid the toolbox icon. It now doesn't reproduce when I disconnect and reconnect external monitor. So… I don't know. If you don't see anything suspicious in those configs, please just close.
And today it reproduced again - got default wallpaper and toolbox visible. So it looks like it happens randomly.
I've had this problem for a few months now. Can't find out what triggers this. Seemingly random every time the computer boots or wakes up from sleep.
*** This bug has been marked as a duplicate of bug 391531 ***
Separate issue, sorry for the noise.
*** Bug 381270 has been marked as a duplicate of this bug. ***
*** Bug 382374 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 373880 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 440995 has been marked as a duplicate of this bug. ***
*** Bug 442455 has been marked as a duplicate of this bug. ***
*** Bug 369450 has been marked as a duplicate of this bug. ***
*** Bug 442438 has been marked as a duplicate of this bug. ***
*** Bug 426886 has been marked as a duplicate of this bug. ***
*** Bug 443274 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #18) > *** Bug 369450 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. ***
I see duplicates still coming in.. can someone with this issue see if it still happens on 5.24/master?
Indeed, I cannot reproduce it in Plasma 5.24 on Wayland. Can folks who have experienced this test the Plasma 5.24 beta (or the final release in a few weeks) to see if it still happens for them? Please make sure to mention if you're using X11 or Wayland, and what kind of multiscreen setup you have: laptop or desktop, and what kind of connector the monitors use.
Might be related to this issue - if the behaviour occurs, I tried to logout again and unplug my monitor from my laptop screen to check if it really is related to the 2nd monitor. So i logged out of the KDE session. Once unplugged, I expected the login SDDM to appear again, but the screen remained black . The cursor was there and in terms of "space" it seemed that the 2nd monitor was still considered active. Once I plugged the monitor in again, I could see the cursor on my 2nd screen. However, the SDDM never showed up again and I had to shutdown via power button. X11, KDE Plasma 5.22.5
Please test with Plasma 5.24 (the beta or the final releases in a few weeks) as all the fixes have gone into that version.
*** Bug 448963 has been marked as a duplicate of this bug. ***
Got a report from the 5.24 beta (Bug 448963); re-opening.
Hi folks, I don't know is it make sense for investigation, but for my curiosity I was tried to research it myself. I've using desktop Intel UHD630 with two monitors, primary on DP and secondary on HDMI. And on my setup I need often to effectively unplug-plug DP monitor via KVM switch, while HDMI connected permanently, so I experiencing this kind of bugs a lot during work. Maybe this bug related to "Primary Monitor" feature? If I remove Q_EMIT primaryOutputChanged(primary); in Platform::setPrimaryOutput I can switch monitor back and forth and plasmashell doesn't loose containment on secondary monitor. I've spot another strange behavior with Primary Monitor feature and commented this https://invent.kde.org/plasma/kwin/-/commit/f91ae3e97584767d273479c4013a43e279d77f40#note_383499 but not really sure is it related or not. PS: A bit off-topic, but can we introduce settings for ignoring hot-plug events from monitors? I actually can use wayland only after removing updateOutputs from DrmBackend::handleUdevEvent, otherwise after switching KVM back and forth some windows on desktop changes their positions, a bit annoying.
*** Bug 446316 has been marked as a duplicate of this bug. ***
*** Bug 447388 has been marked as a duplicate of this bug. ***
Cross-posting from bug 447388, as advised by Nate Graham: Okay, I've finally found some time for some more extensive testing. To remove some variables out of the equation, I purged my appletsrc, changed the wallpapers for both my activities (I have two with different wallpapers) and rebooted a few times. I can attach the config file, but I believe the changes between runs are more interesting: After the first reboot, the path to the wallpaper changes and a new containment is added: @@ -22,7 +22,7 @@ DialogWidth=800 [Containments][1][Wallpaper][org.kde.image][General] -Image=/usr/share/wallpapers/SafeLanding/ +Image=file:///usr/share/wallpapers/SafeLanding/contents/images/5120x2880.jpg SlidePaths=/home/mziab/.local/share/wallpapers,/usr/share/wallpapers [Containments][2] @@ -92,6 +92,20 @@ Image=/usr/share/wallpapers/OneStandsOut/ SlidePaths=/home/mziab/.local/share/wallpapers,/usr/share/wallpapers +[Containments][25] +ItemGeometries-1920x1080= +ItemGeometriesHorizontal= +activityId=c850a35c-21b5-4a3d-a501-e439889d7d98 +formfactor=0 +immutability=1 +lastScreen=2 +location=0 +plugin=org.kde.plasma.folder +wallpaperplugin=org.kde.image + +[Containments][25][Wallpaper][org.kde.image][General] +Image=file:///usr/share/wallpapers/Next/contents/images/1920x1080.png + [Containments][8] activityId= formfactor=2 On the next reboot, the wallpaper path changes again, for the other activity, it seems: @@ -89,7 +89,7 @@ DialogWidth=800 [Containments][24][Wallpaper][org.kde.image][General] -Image=/usr/share/wallpapers/OneStandsOut/ +Image=file:///usr/share/wallpapers/OneStandsOut/contents/images/1920x1080.jpg SlidePaths=/home/mziab/.local/share/wallpapers,/usr/share/wallpapers [Containments][25] Then it changes again on the next reboot: @@ -89,7 +89,7 @@ DialogWidth=800 [Containments][24][Wallpaper][org.kde.image][General] -Image=file:///usr/share/wallpapers/OneStandsOut/contents/images/1920x1080.jpg +Image=file:///usr/share/wallpapers/OneStandsOut/contents/images/2560x1600.jpg SlidePaths=/home/mziab/.local/share/wallpapers,/usr/share/wallpapers [Containments][25] As a reminder, this is an X11 install with two screens, a 1080p one and a 4k one. The latter is set to clone the first one (without scaling) for convenience. It's possible that there are TWO bugs at play here. The changing wallpaper paths might also warrant some scrutiny, but the bug happens with my own wallpapers with no multiple versions for different resolutions, so it's likely not the main culprit. I have conclusive evidence that disconnecting the TV works around the bug. After doing that I couldn't reproduce it, the proper wallpaper appeared instantly. With the TV plugged in, the wallpaper would change to the proper one after 40 or so seconds. Sorry if this is hard to read. I can post more info, just tell me what you need. Please note that this is still on Plasma 5.23, but I got the exact same bug on Plasma 5.23.90, so whatever causes it isn't yet fixed.
I've found something that might also be related. My systemd journal (I'm using the systemd session) has a dozen or so instances of this just a few seconds after boot: plasmashell[584]: requesting unexisting screen 2 Moreover, I'm getting the same message with screen -1 every 15 minutes or so, which seems worrying. I'll try to remove one of my activities and see if it still happens with a single one. For the record, I have tried removing and recreating both activities and it didn't fix the issue.
Created attachment 146124 [details] appletsrc after a few reboots I'm attaching my appletsrc after a few reboots with the other screen turned on, just in case.
Created attachment 146126 [details] kactivitymanagerdrc Also attaching my kactivitymanagerdrc (before removing the second activity) for reference.
After testing for a few days, I can say pretty conclusively that removing the second activity seems to have resolved the issue. So whatever it is, it seems to be triggered by the combination of multi-screen (different native resolutions might also be at play) AND multiple activities.
It seems I've spoken too soon. The bug still appears, but seems much harder to trigger without multiple activities. I've gone through several reboots not being able to replicate it until it suddenly happened. So while multiple activities seem to exacerbate the issue, the only real constant is having multiple screens. Is there anything else I could to help debug this?
Thanks, you've already provided a lot of information. Now I think we just need to wait for a developer with relevant knowledge to see if it can be used to pinpoint the bug and fix it.
A little update: the situation seems to have changed in that now I reliably get a black background which fixes itself in about 30 seconds. Which begs the question - is there some kind of preset timeout somewhere in plasma-shell or kscreen code, after which the outputs are re-probed or the containment is updated? Unlike what I reported earlier, now the behavior is totally reproducible. My educated guess is that there is a race condition between plasma-shell and kscreen. The latter is probably reconfiguring my other screen to be 1080p AFTER Plasma is already running and the containment has been created. I haven't mentioned it, since it didn't seem relevant at the time, but I'm using systemdBoot=true. It's probably worth seeing if forcing plasma-kscreen.service to start before plasma-plasmashell.service (but after plasma-kwin_x11.service, I assume?) changes anything.
What Plasma version are you using, Michal?
I'm currently on Plasma 5.24.5. And I'm fairly positive that I've been getting the black background consistently ever since upgrading to the 5.24 series.
Yeah unfortunately it seems like something in 5.24 regressed this to be even worse than it was in 5.23 and earlier. The good news is that we think we've fixed it in 5.25, which will be released tomorrow. So I would encourage everyone to upgrade and give it a try.
I just had it happen to me again on 5.25. I also use a multi-monitor(usually 2 external monitors) and multi activities setup. I'm a laptop users and I connect to many different monitors during the day(I'm a hot desking user). For me it always happens upon switching to another desk with a different set of monitors. It seems that kde doesn't recognize the new monitor(s) or recognizes them too late or relabels the monitor. Then it thinks the new setup has no activity(containment) and decides to create a new activity(containment) for each monitor which makes me lose my old activities(containments). It won't switch back either since the new one is working fine and now the default. Only very occasionally does it revert back)
Forgot to mention. I'm on Xorg.
Yes, unfortunately Plasma 5.25 didn't fix anything for me. Still getting a black background for the first 30 or so seconds. It doesn't even have to be a full reboot. Logging out and in again also causes the issue to happen. Tried to make sure plasma-plasmashell and plasma-kwin_x11 start after plasma-kscreen by adding this systemd config override for each (what I alluded to in comment #44): [Unit] After=plasma-kscreen.service Wants=plasma-kscreen.service While it didn't break anything, it didn't fix the bug either. Looking at the timestamps, all three services seem to be starting concurrently still, so I guess the override didn't work. Can anyone familiar with the code weigh in on where the 30 second timeout before the containment fixes itself comes from? I see a TimeoutSec=40sec in plasma-plasmashell.service, but that can't be it, right? The shell does start and the panel is present, it's just the wallpaper that's missing, so it's not as though the entire service is timing out.
I've added a 5-second delay before plasma-plasmashell.service is run with this override: [Service] ExecStartPre=sleep 5 While not ideal, this seems to have worked around my missing wallpaper bug. This confirms my theory that plasmashell is starting too early, before screens are properly configured. I have no clue how one would properly resolve this.
That seems like a useful data point, thanks.
Plasmashell always was racey against initial screen configuration. In theory it should be no different to a runtime change which should always "just work" correctly. Adding the sleep is a good data point as you say, but it's masking the symptoms of something else.
> It seems that kde doesn't recognize the new monitor(s) or recognizes them too late or relabels the monitor. > Then it thinks the new setup has no activity(containment) and decides to create a new activity(containment) for each monitor which makes me lose my old activities(containments). > It won't switch back either since the new one is working fine and now the default. Only very occasionally does it revert back) Using kwin git master (5.26.80) and two screens, I can confirm it: After plugging in/out my secondary HDMI screen several times in a row (with 30s pause in between), the custom wallpaper and clock widget were suddenly lost. The wallpaper was replaced by the default Plasma 5.25 wallpaper. Since it's not always absolutely reproducible, it looks indeed like some race condition issues.
For what it's worth, this seems to be fixed in Plasma 5.27. Even with my sleep workaround disabled, I get my wallpaper instantly, just like expected.
Still happens to me, although less frequent. When that happens it also moves windows from that monitor to the other monitor. Plasma 5.27.
Glad to hear it's fixed in 5.27, finally! Jaap, please submit a new bug report for your issue. There's almost no chance it's the exact same thing as this one. And before you do, please read https://notmart.org/blog/2023/02/how-to-report-multiscreen-bugs. Thanks!