The splash screen is shown too long (about 32 seconds) while starting KDE. If I edit the startkde script to disable the splash screen, then the KDE desktop appears and is usable in about 7 seconds. Please let me know what more information you need to debug this. I would try to figure out what the splash screen is waiting for, but I don't know where to start since there is very little information displayed (only the KDE symbol and a progress bar). I recall that back in KDE 3.x the splash screen would display pulsing icons as different components were loaded--maybe it would be a good idea to bring back this feature. Reproducible: Always Steps to Reproduce: 1. Create a clean user profile. 2. Log in to an xterm session. 3. Run startkde. Actual Results: Splash screen is displayed for ~32 seconds. Expected Results: Splash screen should disappear once KDE is started. This seems to be a regression in KDE 5.4; I don't recall it occurring in 5.3 or earlier.
Thanks for the report > I recall that back in KDE 3.x the splash screen would display pulsing icons as different components were loaded--maybe it would be a good idea to bring back this feature. Fwiw, that wouldn't tell much anyway :) Is there any output on the xterm? Is there something related perhaps in syslog/~/.xsession_errors (look for ksmserver/ksplashqml)? Could you perhaps edit the startkde script and add running bustle-pcap somewhere after the dbus session is created and then post the output? That would show the dbus communication with ksplash and would help pinpoint where the bug is.
Created attachment 94407 [details] Start D-Bus sooner Well ... I solved this by accident while I was trying to get bustle working. Apparently startkde needs to start the D-Bus session sooner for the splash screen to work properly. See attached patch. With this fix, the progress bar in the splash screen now moves along pretty quickly (before, it was stuck at zero for the full 30 seconds), and the splash screen disappears after a few seconds.
No longer NEEDSINFO.
Thanks, good stuff. Please post the patch to git.reviewboard.kde.org - review group plasma.
Patch definitely makes sense; ksplash was ported to use DBus in the 5.x transition, this wasn't updated. I'm curious why we need it at all though; this was a last resort check if something went wrong; from the DCOP->DBus transition at the start of Plasma 4. I ask because for the startplasma script that's wayland based this'll be too late as kwin starts first What DisplayManager do you use?
Created attachment 94433 [details] Another solution It is a home-baked display manager, which is currently set up to log in to a very minimal environment for testing purposes--only PAM authenticated and then an xterm started. So in this case there is no D-Bus session active before running startkde. I have found another way to solve this, which is to remove the dbus-launch section entirely from the startkde script. It appears that--contrary to the comment in the script--D-Bus autolaunch does work correctly. Only, it does not export DBUS_SESSION_BUS_ADDRESS to the script environment. So the simplistic test in the script (test -z "$DBUS_SESSION_BUS_ADDRESS") fails, and another D-Bus session is started. Therefore ksplashqml and ksmserver end up trying to talk on different D-Bus sessions.
Git commit f949f161a77114203d0489b2020011be019b47d0 by David Edmundson. Committed on 14/10/2015 at 16:25. Pushed by davidedmundson into branch 'master'. Don't assume dbus-launch autolaunch is still broken 1) it's not broken, that comment is ancient 2) the test is bust. DBus path can also be stored as an x property. Before this patch the situation is worse as potentially we risk launching two dbus daemons for the same session. REVIEW: 125637 M +0 -4 startkde/startkde.cmake M +0 -4 startkde/startplasmacompositor.cmake http://commits.kde.org/plasma-workspace/f949f161a77114203d0489b2020011be019b47d0