Summary: | Spontaneously adding desktop containments at startup | ||
---|---|---|---|
Product: | [Plasma] plasmashell | Reporter: | Antonino Sergi <antserg> |
Component: | general | Assignee: | David Edmundson <kde> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | bhush94, elvstone, nfd, plasma-bugs |
Priority: | NOR | Keywords: | triaged |
Version: | 5.3.2 | ||
Target Milestone: | 1.0 | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | .config/plasma-org.kde.plasma.desktop-appletsrc |
Description
Antonino Sergi
2015-08-08 07:46:50 UTC
Created attachment 93944 [details]
.config/plasma-org.kde.plasma.desktop-appletsrc
Thanks, can you also describe your screen configuration and provide the output of xrandr -q It's not clear to me what you mean by screen configuration, but it's a single screen with 9 virtual desktops and only 1 activity (the default one). xrandr -q Screen 0: minimum 64 x 64, current 1920 x 975, maximum 32766 x 32766 VGA-0 connected primary 1920x975+0+0 0mm x 0mm 1920x975 60.00*+ 2560x1600 60.00 2560x1440 60.00 2048x1536 60.00 1920x1600 60.00 1920x1080 60.00 1600x1200 60.00 1680x1050 60.00 1400x1050 60.00 1280x1024 60.00 1024x768 60.00 800x600 60.00 640x480 60.00 Also on Fedora 22, I recently had similar symptoms (no widgets on desktop) at first KDE login until I upgraded to KDE frameworks 5.15, see https://bugzilla.redhat.com/show_bug.cgi?id=1269004 plasma-workspace 5.4.1-3-fc22 has a delay over 20 seconds upon login (In reply to Fredy Neeser from comment #4) > Also on Fedora 22, I recently had similar symptoms (no widgets on desktop) > at first KDE login until I upgraded to KDE frameworks 5.15 Actually, the problem still exists during the first KDE login after boot, see Comment 17 of https://bugzilla.redhat.com/show_bug.cgi?id=1269004 plasma-workspace 5.4.1-3-fc22 has a delay over 20 seconds upon login and it has something to do with the order / timing in which LVDS and the external monitor are being activated during KDE login. From what I can see on my virtual machine, the issue has been somehow resolved. I use it with 2 different hosts, win10 and linux; on win10 it was doing what I described above, while on linux it was exhibiting some crazy behaviour, like having windows alive and interactive, but not visible because covered by a wallpaper, or an unstoppable memory allocation at login, resulting in a crash of the whole VM. Now everything seems to be back to normal. Due to incorrectly added desktop containments (which I also observed in ~/.config/plasma-org.kde.plasma.desktop-appletsrc), I am getting a broken KDE desktop in Fedora 22, in roughly every second boot/first-login attempt. This is on a laptop with LVDS and an external monitor, where the latter is configured as my primary display. Note that the external monitor is in "Power Save Mode" before KDE login (where the SDDM greeter screen is shown on the LVDS), which may have an effect on the order in which the displays become visible to plasmashell. Here's what happens in an unsuccessful first-login-after-boot: - Primary display visibly moves from LVDS to external monitor - External monitor then shows a KDE panel on blue wallpaper but no widgets, and the LVDS turns black but is otherwise working. From this I can usually recover to a working desktop by doing one or more logout/login cycles. It looks like the first KDE login after boot is critical: When it works, subsequent logout/login cycles typically also work; when it doesn't, it's more likely that a subsequent logout/login cycle also has a problem. If I repeat logout/login cycles, it eventually works. I captured the KDE debug messages for the good and the bad first logins after boot, and they show strong signs of race conditions: In the bad case, kded5/kscreen starts much later in the KDE startup than in the good case, and very late in KDE startup, plasmashell notes that 2015-10-24T22:53:21 plasmashell(2232)/default unknown: primary changed! "LVDS1" "DP-1-2" which does not happen in the good case. Any idea what might go wrong here? In /plasma-workspace-5.4.2/shell/shellcorona.cpp, I found this code snippet: //FIXME ideally fix this, or at least document the crap out of it int screen = containment->lastScreen(); if (screen < 0) { screen = m_desktopContainments[containment->activity()].count(); qDebug() << "last screen is < 0 so putting containment on screen " << screen; } insertContainment(containment->activity(), screen, containment); Does anyone know why one might get screen < 0 and what kind of "crap" one can expect when this happens? I'm also hitting these problems (see my comments on https://bugs.kde.org/show_bug.cgi?id=356899 which I think may be related to this). Desktop Settings were not persisted properly across re-logins for me, and I discovered that I get extra containments added in ~/.config/plasma-org.kde.plasma.desktop-appletsrc_after (see my attachments on the other bug). The settings I apply get saved to a containement with lastScreen=-1, probably somehow due to these (from .xsession-errors): last screen is < 0 so putting containment on screen 0 last screen is < 0 so putting containment on screen 1 requesting config for "Desktop" without a containment! as mentioned by Fredy above. I also have spurious: kscreen: Primary output changed from KScreen::Output(Id: 73 , Name: "VGA1" ) ( "VGA1" ) to KScreen::Output(Id: 73 , Name: "VGA1" ) ( "VGA1" ) occurring in .xsession-errors, both before and after those "last screen..." warnings. So I think somehow Plasma is confused about what is the current screen to which the settings should be applied? I know that Qt 5.6 will have several fixes and improvements re. screen handling and XCB, but could something be done now? This is on Arch Linux with Qt 5.5.1 and Plasma 5.5.1. I have one internal LVDS1, which was not active during these tests. I only used the external (VGA1) output. I should note also that I use xrandr to change monitors normally, since doing so through System Settings has resulted in crashes in Plasma and Qt (via Plasma) (should also become better with Qt 5.6). This bug is NEEDSINFO / WAITINGFORINFO. What more information is needed? (In my comment above I said ~/.config/plasma-org.kde.plasma.desktop-appletsrc_after, this was a paste-o and I of course meant ~/.config/plasma-org.kde.plasma.desktop-appletsrc. The former was just the filename I gave it when I copied it aside for attachment to bug 356899.) 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! |