Bug 352251 - [PATCH] Splash screen is shown too long (30+ seconds) during startup
Summary: [PATCH] Splash screen is shown too long (30+ seconds) during startup
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (show other bugs)
Version: 5.4.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: 1.0
Assignee: David Edmundson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-04 04:18 UTC by John Lindgren
Modified: 2015-10-14 16:26 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Start D-Bus sooner (1.44 KB, patch)
2015-09-05 03:01 UTC, John Lindgren
Details
Another solution (852 bytes, patch)
2015-09-06 19:20 UTC, John Lindgren
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Lindgren 2015-09-04 04:18:19 UTC
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.
Comment 1 Martin Klapetek 2015-09-04 16:17:34 UTC
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.
Comment 2 John Lindgren 2015-09-05 03:01:48 UTC
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.
Comment 3 John Lindgren 2015-09-05 03:02:44 UTC
No longer NEEDSINFO.
Comment 4 Martin Klapetek 2015-09-05 19:13:22 UTC
Thanks, good stuff. Please post the patch to git.reviewboard.kde.org - review group plasma.
Comment 5 David Edmundson 2015-09-06 18:49:19 UTC
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?
Comment 6 John Lindgren 2015-09-06 19:20:38 UTC
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.
Comment 7 David Edmundson 2015-10-14 16:26:04 UTC
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