Bug 354111

I'm not convinced it's multiscreen related. You can test quite easily by unplugging all but one.

I need something to go on: 
ideally a log of bootchart
or a copy of ~/.xsession-errors.

We just fixed a bug that affected Kubuntu (and AFAIK only kubuntu) where there was a timeout for 30 seconds if we couldn't talk to BlueZ. Could be related.

Alright, so I did some more testing to confirm that my suspicion/observation. Firstly I was describe in detail what occurs in the videos so it will be easy to contrast with what differs in my tests.

Standard boot
============

When booting, you see all the flashing, lines across screen, and finally center screen turns off (although it never says it has no signal, but the blue light indicating signal flashes which is interesting. Based on observation that seems to mean it has some sort of signal, but doesn't display it. Keep in mind that it does not indicate any issue with resolution as I've seen messages when no signal or resolution is incompatible with monitor. To me this indicates a blank signal or somesuch since it also displays pure black.

- Login screen displays on each 1920x1200 dvi monitors, but not the 2560x1600 display port monitor.
- Post login partial animation then black.
- Various application startup noises and notifications can be heard in background.
- Windows are oddly sized looks like they loaded when resolution was tiny as they are very small.
- After long delay everything loads.

No DVI monitors plugged in, only 2560x1600 display port boot
====================================================

- Login screen displays on the 2560x1600 display port monitor.
- Post login full animation.
- Quick login and proper fade to desktop with no issues.

I repeated this 5 times with the same result. Confirms what I've seen on single monitor setups.

No DVI monitors plugged in, only 2560x1600 display port boot. Then plugin DVI monitors at login screen
=======================================================================================

- Login screen displays on the 2560x1600 display port monitor.
- Post login full animation.
- Hangs at 100% for long period while normal things happen behind scenes.
- Various application startup noises and notifications can be heard in background. (notifications can also bee seen on top of login animation since monitors are not all black)
- I do not believe any odd sized windows, but that could be a fluke.
- After long delay everything loads.


Conclusion
=========

From what I've seen:
- the first issue is that the DVI monitor never loads properly at login screen when other two monitors are present. Perhaps something to do with different resolutions since the two monitors with the same resolution have no issues
- following on resolution difference seems to show the monitors resizing and such based on tiny windows and similar result if I boot up and login with single monitor and use kde to enable other two monitors, it is also slow. additionally if you look at the pre qt 5.5 video you can witness the shifting of picture and such like the resolution is changing
- the last test seems to prove what I heard/suspected was correct in that applications startup quickly, but login screen does not go away
- the second test seems to confirm this has something to do with >1 monitor (as on other setups) and possibly with different resolution monitors.

I will run 4th test by booting with only the DVI monitors plugged in and report back. I will also post the .xsession-errors-:0 file.

Created attachment 95169 [details]
xsession-errors-:0 (from final boot in above description)

This should be representative since final boot had long delay even though it was not all black.

Only DVI monitors 1920x1200 plugged in
==================================

- Same as single monitor test in last set (ie quick login)

Conclusion
==========

- This could confirm the resolution theory and/or be related to the fact that those monitors display the login screen properly in all scenarios.
- Alternatively this could have to do with different interfaces dvi vs display port, but that would seem unlikely since I imagine only the video drivers handle anything remotely close to that and this only has issues during login. If it were driver related I would expect it to always occur or at least at various stages.

I will follow this up with the .x-session-errors-:0 from the two monitor fast login.

Created attachment 95171 [details]
.x-session-errors-:0 from the two monitor fast login

I have also tried the 3 monitor setup several times on fresh user account with the same results (slow login).

Created attachment 95172 [details]
ksysguard after a slow login

This is an example of the small window size after a slow login. Happens to steam friend list most frequently.

Note sure if this is relevant for boot (from systemd). http://i.imgur.com/ynGF5S1.jpg

After my experiments the following has been the case for the last few days which seems to confirm my findings since you can actually see the desktop and applications loaded behind the login screen, but it refuses to go away.

http://i.imgur.com/0JS1DTJ.jpg

One think I note in the logs is that the "Primary output changed from " 10 times (yikes..really?!) in fast boot and 12 in slow boot.

Given that it seems to start plasma 5 quickly and load applications it appears as if whatever mechanism is responsible for signalling a completed login just sits there and waits. This is definitely different from what I was pre qt 5.5 so perhaps there were two parts to this bug and qt 5.5 resolved the slow modsetting and display setup, but now I'm left with this oddity.

If those cc'd have a second could someone at least point me to the code responsible for this? I assume there are a few parts ssdm being one of them? or is that purely the login screen and once you press enter plasma 5 takes over?

>If those cc'd have a second could someone at least point me to the code responsible for this? I assume there are a few parts ssdm being one of them? or is that purely the login screen and once you press enter plasma 5 takes over?

SDDM is not involved.

Code you want is in ksplash for receving signals and across kwin, ksmserver and plasmashell for sending their signal. All (except kwin) are in the repo plasma-workspace.

i have the same problem. A clean kde config (deleting .kde* .config .local) provides a fast login but after attaching and using external screens the login in kde takes 10-15 seconds compared to 2 seconds before using multiple screens. detaching all screens also solves the slow login. Another workaround is the disable the splash screen. After disabling the help screen the login works as fast as with a clean config, so i would say the problem is the splash screen at least for my config

(In reply to rauchwolke from comment #13)
> i have the same problem. A clean kde config (deleting .kde* .config .local)
> provides a fast login but after attaching and using external screens the
> login in kde takes 10-15 seconds compared to 2 seconds before using multiple
> screens. detaching all screens also solves the slow login. Another
> workaround is the disable the splash screen. After disabling the help screen
> the login works as fast as with a clean config, so i would say the problem
> is the splash screen at least for my config

help screen = splash screen

compared to the youtube link the splash screen hangs for me so i have a stuck splash screen for a few seconds (10-15) instead of a blank screen

I no longer see the blank screen, but the long waits still remain. The behavior is tweaked now and again with different releases and it's been worse at certain times than other, but never resolved.

I do not see an appropriate status that I can set this issue, but "WAITINGFORINFO" definitely is not the case.

(In reply to Jimmy Berry from comment #16)
> I do not see an appropriate status that I can set this issue, but
> "WAITINGFORINFO" definitely is not the case.

Did you try do disable the splash screen?

(In reply to Jim Jones from comment #17)
> (In reply to Jimmy Berry from comment #16)
> > I do not see an appropriate status that I can set this issue, but
> > "WAITINGFORINFO" definitely is not the case.
> 
> Did you try do disable the splash screen?

I am not sure how to accomplish such a feat. There does not appear to be any such setting in sddm via gui or config file. To what specifically are you referring?

(In reply to Jimmy Berry from comment #18)
> (In reply to Jim Jones from comment #17)
> > (In reply to Jimmy Berry from comment #16)
> > > I do not see an appropriate status that I can set this issue, but
> > > "WAITINGFORINFO" definitely is not the case.
> > 
> > Did you try do disable the splash screen?
> 
> I am not sure how to accomplish such a feat. There does not appear to be any
> such setting in sddm via gui or config file. To what specifically are you
> referring?

Disabled in "systemsettings5 => workspace theme => splash screen" which does in fact work around the issue.

Can confirm this, glad I’m not the only one. Disabling the splash screen does indeed work around the issue. On, it takes my AMD FX-8350 with SSD 32 sec to fully login vs 7 sec with second monitor disconnected.
This bug clearly needs to be resolved. I’m actually baffled that this is a thing at all. One would assume that the KDE dev group would have some overlap with the group of power users having multiple monitor setups.
How can I provide the needed infos?

Maximilian, which Plasma version are you using? Note that this bug report is quite old.

I’m on Plasma 5.10.5 on Antergos.

Thanks for the update; changing status.

I am not yet sure what additional information could be useful, but your comment about the splash screen might already give a hint.

Maybe this could help: I’m using different resolutions on my two monitors. One at UHD and one at FHD.

KSplash closes itself when plasma reports that it has finished started up.

There's a failsafe where after 30 seconds it will close itself regardless. 

What we're probably seeing is plasmashell get confused as to which panels it's loading, and then never report anything; not helped that kscreen configures its monitors mid-load.

Max, can you include your ~/.local/share/sddm/xorg-session log after startup.

Antergos uses LightDM instead of SDDM, so I switched over to SDDM to get the log file. To my surprise, the first login was as fast as with only one monitor – but the second login was slow again, a third after a reboot still.
Look for the xorg-session.log.

Created attachment 108080 [details]
xorg-session.log

You described 3 scenarios and I have one log.
Which one is it of?

If anything he added one additional piece of information that this may occur on sddm session post the first one. If you look at the original report is a bout sddm and the user (myself) had been using this machine for quite some time, but after an update this occurred.

Therefore the new report of it only occurring after the second login post switching to sddm is simply a new bit of information that does not contradict the previous information.

From the other report this problem can also occur outside of sddm. Again these are additive facts that point to one problem...not different bugs.

>Antergos uses LightDM instead of SDDM, so I switched over to SDDM to get the log file. To my surprise, the first login was as fast as with only one monitor – but the second login was slow again, a third after a reboot still.
Look for the xorg-session.log.

I'm still waiting to hear which one of those 3 boots is this Xorg.conf log is from.

I would assume my log was from the last login when it was slow. Now on Plasma 5.12, I can’t reproduce it anymore, so maybe it is already fixed? I have logged in a couple times with login splash on and it needed more or less the same amount of time as without splash.

Jimmy, is it also fixed for you with Plasma 5.12?

Yes