Bug 482082 - Plasma takes an extra 33 seconds to start after entering password and logging in when choosing the Breeze Splash Screen
Summary: Plasma takes an extra 33 seconds to start after entering password and logging...
Status: RESOLVED DUPLICATE of bug 482267
Alias: None
Product: plasmashell
Classification: Plasma
Component: Startup process (show other bugs)
Version: 6.0.0
Platform: Other Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: qt6
Depends on:
Blocks:
 
Reported: 2024-02-29 19:39 UTC by Kevin R
Modified: 2024-03-12 16:21 UTC (History)
8 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin R 2024-02-29 19:39:59 UTC
SUMMARY
By default, the Breeze Splash screen is enabled. I noticed the system took a long time to log in after entering my password after upgrading to Neon / Plasma 6. I went to disable to splash screen in order to look at the text of what was being loaded and this time logging in to the desktop was almost instantaneous.

STEPS TO REPRODUCE - Problem
1. Go to Settings > Colors & Themes > Splash Screen
2. Select Breeze 
3. Reboot

OBSERVED RESULT
After entering password, the Breeze splash shows for about 33 seconds before the desktop appears.

EXPECTED RESULT
Logging in should be a LOT quicker than 33 seconds.

----

ADDITIONAL STEPS TO REPRODUCE - Problem
1. Go to Settings > Colors & Themes > Splash Screen
2. Select None
3. Reboot

OBSERVED RESULT
After entering password, the desktop loads almost instantaneously. 


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Neon / Plasma 6
KDE Plasma Version: 6.0.0
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2

ADDITIONAL INFORMATION
There are no "new" splash screens available yet for Plasma 6, so I was unable to test other splash screens.
Comment 1 tagwerk19 2024-02-29 20:53:47 UTC
Run journalctl and see if you have bluetooth related failures, see Bug 481870
Comment 2 tagwerk19 2024-02-29 21:32:04 UTC
(In reply to Kevin R from comment #0)
> ... I went to disable to splash screen in order to look at the text of
> what was being loaded and this time logging in to the desktop was almost
> instantaneous ... 
That's disabling the Splash Screen in the System Settings > Colors and Themes > Splash Screen?

As far as I can tell, that didn't make a difference for me.
Comment 3 duha.bugs 2024-02-29 22:08:37 UTC
Confirming: affecting users on discuss aswell: https://discuss.kde.org/t/slow-desktop-loading-plasma-6/10749/21?u=duha
Comment 4 Peter Ped Helcmanovsky 2024-03-01 00:56:59 UTC
Disabling splash screen brings the wayland login time from ~30s down to ~2.5s for me too.

Still feels like extra 1.5s more than the X11 login time, but now I would need stopwatch to be sure it's not placebo.

The X11 session is still ~1s login time even after Plasma 6 upgrade, just like it was before, but I used Wayland first time ever by accident (it was default after upgrade) and it took those ~30s, also after logout/restart (well, once I fixed those as they were not working after upgrade too). Going to test X11 without splash screen if it didn't get slower (to match ~2.5s of Wayland), but if there's no edit/comment from me, then X11 behaves normally with ~1s login.
Comment 5 tagwerk19 2024-03-01 08:45:15 UTC
There must be more than one issue in play here...

I've tried setting the splash screen to "none" (something that crashed systemsettings) in a test VM. Rebooting and logging on with Wayland and X11, I still get the org.bluez timeout and no difference to the logon delay.
Comment 6 Kevin R 2024-03-01 13:38:56 UTC
(In reply to tagwerk19 from comment #1)
> Run journalctl and see if you have bluetooth related failures, see Bug 481870

I initially checked to see if this was Bluetooth related, as I when I did some google searching that is all I found was people having delayed login due to Bluetooth. However I found out my problem doesn't seem to be related.  I just checked journalctl again after enabling splash and rebooting and it doesn't show any unusual errors related to Bluetooth. The only error I see (which I have always seen with previous versions of Plasma) is "Bluetooth: hci0: Malformed MSFT vendor event: 0x02". So this is "normal" for me. This just seems to be the  splash screen that is delaying login for some reason.

I did look through the journalctl logs and was not able to find anything that could point to the delayed login. However, I don't even know what I am looking for, so someone else might be a better candidate for looking at the logs.
Comment 7 Arjen Hiemstra 2024-03-01 15:00:19 UTC
Just to collect some extra data, can we the output of `systemd-analyze --user blame` for those that can reproduce this bug? While there is something going on with ksplash it'd be useful to exclude other things going wrong.
Comment 8 tagwerk19 2024-03-01 18:38:53 UTC
(In reply to Arjen Hiemstra from comment #7)
> Just to collect some extra data, can we the output of `systemd-analyze
> --user blame` for those that can reproduce this bug? While there is
> something going on with ksplash it'd be useful to exclude other things going
> wrong.
I'm not able to replicate a link to the splash screen, I've copied the "blame" here:
    https://bugs.kde.org/show_bug.cgi?id=481870#c6
Comment 9 Kevin R 2024-03-01 20:38:51 UTC
(In reply to Arjen Hiemstra from comment #7)
> Just to collect some extra data, can we the output of `systemd-analyze
> --user blame` for those that can reproduce this bug? While there is
> something going on with ksplash it'd be useful to exclude other things going
> wrong.

1min 49ms drkonqi-coredump-pickup.service
   2.044s xdg-desktop-portal.service
   1.656s plasma-kcminit.service
   1.582s xdg-desktop-portal-gtk.service
    169ms plasma-powerdevil.service
    143ms plasma-ksmserver.service
    111ms plasma-plasmashell.service
    108ms pulseaudio.service
     89ms plasma-polkit-agent.service
     86ms plasma-xdg-desktop-portal-kde.service
     70ms plasma-kded6.service
     35ms plasma-kactivitymanagerd.service
     20ms plasma-ksplash-ready.service
     17ms obex.service
     16ms plasma-kglobalaccel.service
     13ms kde-baloo.service
     11ms plasma-kwin_wayland.service
      8ms plasma-kcminit-phase1.service
      6ms dbus.socket
      6ms app-kaccess@autostart.service
      6ms xdg-document-portal.service
      5ms plasma-restoresession.service
      5ms app-lts_eol@autostart.service
      5ms app-org.kde.discover.notifier@autostart.service
      4ms session-migration.service
      4ms app-org.kde.kdeconnect.daemon@autostart.service
      3ms xdg-desktop-portal-rewrite-launchers.service
      3ms at-spi-dbus-bus.service
      3ms app-org.kde.xwaylandvideobridge@autostart.service
      2ms app-snap\x2duserd\x2dautostart@autostart.service
      2ms dconf.service
      2ms xdg-permission-store.service
Comment 10 Kevin R 2024-03-01 20:41:40 UTC
(In reply to Arjen Hiemstra from comment #7)
> Just to collect some extra data, can we the output of `systemd-analyze
> --user blame` for those that can reproduce this bug? While there is
> something going on with ksplash it'd be useful to exclude other things going
> wrong.

My previous comment was with the splash screen chosen. Below is with the splash screen as "none" and then I rebooted:

1.969s xdg-desktop-portal.service
1.667s plasma-kcminit.service
1.592s xdg-desktop-portal-gtk.service
 139ms plasma-ksmserver.service
 134ms plasma-powerdevil.service
  92ms plasma-plasmashell.service
  89ms pulseaudio.service
  64ms plasma-polkit-agent.service
  63ms plasma-xdg-desktop-portal-kde.service
  62ms plasma-kded6.service
  34ms plasma-kactivitymanagerd.service
  22ms plasma-kglobalaccel.service
  20ms kde-baloo.service
  13ms plasma-kwin_wayland.service
   8ms plasma-restoresession.service
   7ms app-kaccess@autostart.service
   7ms plasma-kcminit-phase1.service
   6ms plasma-ksplash-ready.service
   6ms dbus.socket
   6ms app-lts_eol@autostart.service
   6ms app-org.kde.discover.notifier@autostart.service
   6ms xdg-document-portal.service
   5ms app-org.kde.kdeconnect.daemon@autostart.service
   4ms app-snap\x2duserd\x2dautostart@autostart.service
   4ms app-org.kde.xwaylandvideobridge@autostart.service
   4ms session-migration.service
   4ms at-spi-dbus-bus.service
   3ms obex.service
   2ms xdg-desktop-portal-rewrite-launchers.service
   2ms dconf.service
   2ms xdg-permission-store.service
Comment 11 Kevin R 2024-03-01 22:03:56 UTC
Just did a system update today and this issue appears to be resolved. I was curious as I saw a file with the name "Breeze" in it and decided to re-enable to splash screen after the update was completed. I rebooted, and lo and behold, the splash screen appeared after I entered my password for about a 1/2 second and then the desktop loaded.
Comment 12 Fushan Wen 2024-03-12 16:21:21 UTC

*** This bug has been marked as a duplicate of bug 482267 ***