Due to the very nice integration with the rest of the desktop, I am using the Breeze theme for SDDM (created by David Edmundson). It looks way better than the default theme of SDDM, but it has one very big disadvantage. When the Breeze theme is active, it takes about 1,5 minute for SDDM to show its login screen. (Measured with systemd-analyze blame). Using the default theme for SDDM (Maui), then it only takes a fraction of a second and systemd-analyze blame doesn't even show a line for it. The only difference that I notice is that is feels that it takes longer for plasma to startup when using the Maui theme, then with the Breeze theme. However these few seconds still doesn't justify the 1,5 minutes startup for SDDM. Reproducible: Always
wow. That's pretty extreme A delay that big must be a DBus timeout (or rather 3 sequential DBus timeouts). We end up querying solid for battery status which does go via an activated kded; so potentially that's where we block. Can you: - confirm what version you are using. - tell me where you get your RPMs from - check the log files from SDDM (journalctl -u sddm)
Created attachment 89915 [details] journalctl -b output with Breeze theme active for SDDM
Created attachment 89916 [details] journalctl -b output with Maldives theme active for SDDM
Hi David, The SDDM version that I am using is from git master and we are building it on openSUSE Build Service. I am part of the openSUSE KDE Community team and we are currently testing SDDM to see if we could make the same switch as Fedora from KDM to SDDM. I am using it in connection with a Frameworks/Plasma-next desktop. SDDM on openSUSE is started through the generic display-manager service. There are indications that we should switch to using separate services for each display-manager, but this has not yet done, so you might see display-manager in the journal logs. Running systemd-analyze blame delivers (top x lines) the following output: 1min 30.078s display-manager.service 560ms ModemManager.service 536ms systemd-tmpfiles-setup.service 500ms systemd-logind.service 499ms firewalld.service 447ms postfix.service 429ms plymouth-read-write.service 214ms mnt-windows.mount 159ms NetworkManager.service 67ms lvm2-activation-net.service 58ms systemd-fsck@dev-disk-by\x2duuid-a15e9da3\x2d0009\x2d4847\x2d978d\x2d34b3de059089.service 42ms alsa-restore.service 40ms avahi-daemon.service So I am not sure if the 1min 30secs is really the time required by SDDM or that it just indicates that a total boot time of 1 min is reached and that 30 secs is used for the display-manager. I have attached two journals (one with the maldives theme active and the other with the breeze theme). These are the full startup journals of the current session. I didn't filter them to prevent loosing information.
I reverted the PowerDevil patch. Please try again with recent PowerDevil. Thanks!
Hi Kai, I hope your didn't revert your patch because of this bug report. I am running the latest version from git, but still the same issue. So the revert didn't bring any relief in the startup time of SDDM
@ Raymond Starting with Plasma 5.5.4 you can select not to have a start screen (with progress-bar) at all System-Settings -> Desktop-Appearance -> Start-Screen (select) Does this speed up your boot? <OT >There's nothing yet from kde-look.org <OT>
Can confirm this for Plasma 5.7.x (K)Ubuntu 16.10 YY.
I think that problem here is more global than just sddm plugin. Slow init can reproduced for a quite big number of Qt5 apps. Maybe linking against libicu causes this issue or opensource graphics drivers. Not sure. Needs further investigation.
Actually I haven't seen this for quite some time. Also with the changes that Plasma 5.8 will bring to the SDDM theme, the issue no longer occurs with me.
Maybe it was fixed with Qt5.7. I have Qt5.6.1.
I also cannot replicate this at all: Plasma 5.7.2, and later 5.7.5 Qt 5.6.1 Ubuntu 16.10 (Yakkety)
Is this still relevant?
Since there have been changes relevant to this bug since it was filed, and folks can no longer reproduce it, let's close it until we get new reports. Thanks everyone!
*** Bug 365710 has been marked as a duplicate of this bug. ***