Bug 431474

Summary:	Laptop resumes from suspend with only external screen enabled
Product:	[Frameworks and Libraries] frameworks-kcoreaddons	Reporter:	Heinz Wiesinger <pprkut>
Component:	general	Assignee:	Michael Pyne <mpyne>
Status:	REPORTED ---
Severity:	normal	CC:	kdelibs-bugs-null, nate
Priority:	NOR
Version First Reported In:	5.79.0
Target Milestone:	---
Platform:	Slackware
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Heinz Wiesinger 2021-01-12 07:16:27 UTC

SUMMARY

After resuming my laptop from suspend with an external display connected to it, plasma only shows on the external display while the internal one is disabled.
I can enable and set it to primary without problems in the KCM, but that was the setting already before suspend.

STEPS TO REPRODUCE
1. Connect external display and extend desktop (dual screen setup)
2. Suspend
3. Resume

OBSERVED RESULT

Internal display (eDP-1) is disabled, external display (HDMI-1) is enabled and primary.

I see this in .local/share/sddm/xorg-session.log

Old primary output: QScreen(0xc06150, name="eDP-1") New primary output: QScreen(0xc06190, name="HDMI-1")

EXPECTED RESULT

Plasma resumes with the same display setup as it was suspended with (provided hardware did not change)

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Slackware-current
(available in About System)
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION

This was working with Plasma 5.19.x

Comment 1 Heinz Wiesinger 2021-01-18 07:04:15 UTC

I did some more observations and I'm no longer sure this is a problem with kscreen, but I wouldn't know where else to look :-/

Here's what I found:

- There is some general lag on resume. In an XFCE session, resume from suspend takes about 1 second until I can enter my password and unlock. In a plasma session, I wait more than 40 seconds until I get the unlock screen, sometimes even longer.
- I noticed that sometimes kdevelop hangs on exit (GUI closed, but process still in the background), which has negative effects on other running applications. Notably krusader became a lot slower browsing the filesystem, with about 2-4 seconds to open a folder. Killing the kdevelop process fixed krusader's lag.

I'm unsure whether these 3 are related, but they might hint at a lower level issue. I initially thought the delay on resume would also be caused by a lingering kdevelop process (it would have made sense), but alas it also happens with no kdevelop process running.

Anyone an idea how I can debug this further?

Comment 2 Heinz Wiesinger 2021-03-06 14:43:49 UTC

I tracked this down to a pthread mutex lock in libfam, used by KDirWatch in libplasma_wallpaper_imageplugin.

I recompiled kcoreaddons with support for FAM disabled, so it's using inotify instead and all issues are gone. Resume is fast, there are no more issues with kscreen and kdevelop is more responsive as well.

What I don't know is what caused it and where *exactly* that bug is. I checked with some other slackware developers and none other experienced the issues I did, even with FAM. So it's not a general issue and either environmental or caused by a combination of apps I'm using.

I'm tempted to say it's just a thread locking issue in FAM directly, and there's nothing that can be done about it in kcoreaddons, especially with inotify working fine. But I would appreciate nonetheless if someone with more knowledge about FAM/inotify could chime in here.