Created attachment 101897 [details] Xorg log file At times, when logging in to my Plasma desktop, instead of my normal layout I'm presented with a default wallpaper desktop and no panel; this happens both with my ordinary user and with a freshly created user with no previous Plasma configuration, but it also seems to happen only when I have my laptop connected to an external monitor (tried a few times with the monitor unplugged and could not reproduce the issue). Logging out and back in takes my normal desktop back. Disconnecting the external monitor while still logged in doesn't change the panel-less desktop. I'm using Mageia Cauldron, currently with Plasma 5.8.2 and Qt 5.6.1. My hardware is an HP Pavilion dv6 6020el connected to an ASUS VE248 monitor via HDMI.
can you post ~/.config/plasmashellrc and ~/.config/plasma-org.kde.plasma.desktop-appletsrc ?
Created attachment 101924 [details] plasmashellrc of ordinary user
Created attachment 101925 [details] applersrc of ordinary user
Created attachment 101926 [details] plasmashellrc of new user
Created attachment 101927 [details] appletsrc of new user
the weird thing is that it seems both plasmashellrc configurations know only about one screen and is different
Forgot to mention I've always been using one screen at a time, i.e when the external monitor is connected the laptop screen is off; I've never used both screen at once so far
Git commit b8d3e09b3687082037a6d280d2032617121ae5e5 by Marco Martin. Committed on 09/11/2016 at 14:54. Pushed by mart into branch 'Plasma/5.8'. make sure all outputs are known at startup, if a screen id is missing from the screenpool mapping containment::screen() will return -1 for a moment in the startup phase even if it has a valid lastScreen populate mappings of eventual missing stuff at screenpool ctor make sure destroyed containments don't get assigned a view reviewed-by: David Edmundson Related: bug 372099, bug 371991, bug 371819, bug 371734 M +11 -0 shell/screenpool.cpp M +7 -1 shell/shellcorona.cpp http://commits.kde.org/plasma-workspace/b8d3e09b3687082037a6d280d2032617121ae5e5
Git commit 8a472f17ce11f3b79d740cdc21096d82b8683f3d by David Edmundson. Committed on 10/11/2016 at 10:28. Pushed by davidedmundson into branch 'Plasma/5.8'. Avoid connecting to screen changed signals twice Summary: load() can be called multiple times; either from setShell or loadLookAndFeelDefaultLayout. We still only want addOutput once when a screen is added Reviewers: #plasma, apol Reviewed By: apol Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D3320 Related: bug 372099, bug 371819, bug 371734 CBUG:371991 M +3 -3 shell/shellcorona.cpp http://commits.kde.org/plasma-workspace/8a472f17ce11f3b79d740cdc21096d82b8683f3d
Git commit 7154fb681adc73c482e862febc7ad008f77058dd by David Edmundson. Committed on 10/11/2016 at 12:03. Pushed by davidedmundson into branch 'Plasma/5.8'. Load screenpool at the same time as we connect to screenchanged signals Summary: Otherwise we have a gap during load (waiting querying kactivities)) between screen pool being created and us connecting to the screen changed signals, which in turn are used to update screen pool. In particular the primary screen can get out of sync between the current state and the screen pool. Test Plan: Based on Christopher Feck's research and initial patch Reviewers: #plasma Subscribers: mart, rwooninck, fvogt, cfeck, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D3319 Related: bug 372099, bug 371819, bug 371734 CBUG:371991 M +1 -0 shell/autotests/screenpooltest.cpp M +8 -0 shell/screenpool.cpp M +1 -0 shell/screenpool.h M +3 -1 shell/shellcorona.cpp http://commits.kde.org/plasma-workspace/7154fb681adc73c482e862febc7ad008f77058dd
*** Bug 372099 has been marked as a duplicate of this bug. ***
*** Bug 372543 has been marked as a duplicate of this bug. ***
I have similar experience like ita84@inwind.it, but in my case there is no external display and never was. In my desktop I have only HDMI socket and connected monitor by standard VGA, but Plasma detects some not existing display. I wrote couple comments from my experiences related with this issue. Last one (Commnet 7) is related with 5.8.4, all previous with 5.8.3 Issue reported here: https://bugs.kde.org/show_bug.cgi?id=372557
Even after an upgade to Plasma 5.8.4 and Qt 5.6.2 I have encountered the issue after a couple reboots, so the fix did not work for me
I haven't encountered the issue in a few days, even though there haven't been any updates to either Plasma (still on 5.8.4) or Qt (5.6.2). Unfortunately I can't confirm when exactly it got solved (it could've been about a week ago), so I can't tell which software updates contained the fix. Possibly related software that was updated recently: - KDE Frameworks (5.27 -> 5.28 2016-12-04 -> 5.29 on 2016-12-13) - KDE Applications (16.08.3 -> 16.11.90 on 2016-12-17) - KDE 4 Workspace (4.11.22 -> distro patch on 2016-12-10) - SDDM (0.14 -> distro patch on 2016-12-10, but doesn't seem to be related) If there's nothing else I can help with you may close the bug. Thanks for your work
I managed to trigger this switching from the nvidia blob to nouveau - the second monitor was using the default configuration rather than my customized one. Restoring plasmashellrc from a good backup did not, however, restore the widgets. I'm thinking the monitors might be recognized differently on different drivers...
Just adding 3 cents. Reported by me issue (with Id: 372557) disappeared after update to Plasma 5.8.5, so maybe driver i915 in Linux kernel didn't work wrong :/. Before update (Plasma) I had to use kernel 4.8.6 or 4.4.x series to avoid reported issue and now 4.8.13 works fine :). Anyway I recommend update to the newest Plasma.
(In reply to Soukyuu from comment #16) > the widgets. I'm thinking the monitors might be recognized differently on > different drivers... yes, that's known. upgrading to 5.8.5 should fix the occasional wrong desktop at startup. the outputs are identified by the driver and desktops are linked to the output, so yes, setup changing when the driver is changed is expected and not something we can do much about
Problem is back again for me: it may have coincided with the upgrade to Plasma 5.8.5 (27th December) or kernel 4.9.0 (today). In any case, this is what is currently installed - KDE Plasma 5.8.5 - KDE Frameworks 5.29 - KDE Applications 16.12.0 - Qt 5.6.2 - KDE 4 Workspace 4.11.22 - SDDM 0.14 - kernel 4.9.0
(In reply to ita84 from comment #19) > Problem is back again for me: it may have coincided with the upgrade to > Plasma 5.8.5 (27th December) or kernel 4.9.0 (today). In any case, this is > what is currently installed now with the problem returned can you post another copy of plasmashellrc and plasma-org.kde.plasma.desktop-appletsrc? also, your multiscreen setup is: 2 screens with the primary screen as the laptop screen, both enabled at startup, right?
Created attachment 103178 [details] plasmashellrc of ordinary user 5.8.5
Created attachment 103179 [details] applersrc of ordinary user 5.8.5
According to System Settings, the primary screen is the external one (HDMI1). I don't know how to determine whether a screen is enabled in Plasma; in any case I leave the laptop closed when booting so it stays off at startup (and all the time)
I should also note that since the occurrence on 2017-01-02 the problem hasn't occurred again (in about 6 reboots), so it might be gone again
i see some suspicious things in the config files: plasmashellrc: there is only one screen 0=HDMI-1 the internal laptop screen doesn't seem to be saved there appletsrc: there are 2 containments (33 and 34) with same activity and same lastscreen, this should never happen (and with a file like that, one of the two are supposed to be removed when the file is saved again) can you attach also ~/.config/kactivitymanagerdrc ? that way i can try a session with the same exact setup
(In reply to ita84 from comment #23) > According to System Settings, the primary screen is the external one > (HDMI1). I don't know how to determine whether a screen is enabled in > Plasma; in any case I leave the laptop closed when booting so it stays off > at startup (and all the time) in the display system settings module, if a screen is disabled, it should look like translucent and tell you explicitly when you click on it. so, as i only see hdmi1 in plasmashellrc, i assume the internal laptop screen is disabled looking around your appletsrc, i see a total of 4 activities, is that correct?
so, the problem seems that an highly corrupted config file from the past bugs is still not correctly cleaned up (there are ~20 or so containments for one activity) so i think sometimes it gets a different containment out of the very long list of available ones. I'll try to be more aggressive with the cleanup of duplicates
this should fix it: https://phabricator.kde.org/D3981
I can confirm that the laptop screen (LVDS1) is disabled. I can also tell you that I've only got a single activity; there used to be 2 (I deleted one a while ago in hopes of fixing the issue), but there have never been 4 as far as I can remember, since I've never created any new activity. Not sure what the mess in appletsrc was caused by. It might be due to the fact that I've gone through all the Plasma upgrades since 5.1; I remember clearing my plasma configuration once or twice upon upgrade because of compatibility issues, but definitely not for every major upgrade. I'll wait until the modification you pointed to is released and see if it works. Still no reoccurrence of the problem so far
Git commit a9abb4ad66a93a9800347c906cbe2003d99e9e0f by Marco Martin. Committed on 10/01/2017 at 15:03. Pushed by mart into branch 'master'. better clean up of duplicate containments Summary: due to old multiscreen bugs, sometimes the appletsrc file gets polluted with a lot of containments with same activity id and lastScreen, in some cases even hundreds (see https://bugs.kde.org/show_bug.cgi?id=371858) in that case we can't be 100% sure what containment will be loaded at startup, leading to an herratical behavior. it was trying to clean up duplicates but wasn't really effective now base upon lastScreen (so we catch other activities as well) and manually remove the destroyed containment from m_desktopContainments (which may sole some multiscreen related bug, such as 371991) Related: bug 371991 Test Plan: started a session with the corrupted appletsrc from the bugreport, file gets cleaned out of duplicates Reviewers: davidedmundson, #plasma Reviewed By: davidedmundson, #plasma Subscribers: davidedmundson, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D3981 M +4 -4 shell/shellcorona.cpp https://commits.kde.org/plasma-workspace/a9abb4ad66a93a9800347c906cbe2003d99e9e0f
Git commit 19a88030d3de12a96402a1103c964e5a7363646c by Marco Martin. Committed on 10/01/2017 at 15:06. Pushed by mart into branch 'Plasma/5.8'. better clean up of duplicate containments Summary: due to old multiscreen bugs, sometimes the appletsrc file gets polluted with a lot of containments with same activity id and lastScreen, in some cases even hundreds (see https://bugs.kde.org/show_bug.cgi?id=371858) in that case we can't be 100% sure what containment will be loaded at startup, leading to an herratical behavior. it was trying to clean up duplicates but wasn't really effective now base upon lastScreen (so we catch other activities as well) and manually remove the destroyed containment from m_desktopContainments (which may sole some multiscreen related bug, such as 371991) Related: bug 371991 Test Plan: started a session with the corrupted appletsrc from the bugreport, file gets cleaned out of duplicates Reviewers: davidedmundson, #plasma Reviewed By: davidedmundson, #plasma Subscribers: davidedmundson, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D3981 M +4 -4 shell/shellcorona.cpp https://commits.kde.org/plasma-workspace/19a88030d3de12a96402a1103c964e5a7363646c