Bug 354437 - [regression/4] KScreen does not remember multiple monitor configuration
Summary: [regression/4] KScreen does not remember multiple monitor configuration
Status: RESOLVED WORKSFORME
Alias: None
Product: KScreen
Classification: Plasma
Component: common (show other bugs)
Version: 5.4.2
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Daniel Vrátil
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2015-10-27 06:43 UTC by Thiago Macieira
Modified: 2018-10-27 03:57 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thiago Macieira 2015-10-27 06:43:45 UTC
KScreen is not remembering the configuration for different monitors like it used to in KDE 4 workspaces.

Reproducible: Always

Steps to Reproduce:
1. Plug a monitor and configure it for duplicating the laptop screen
2. Unplug this monitor and plug a different monitor
3. Configure the monitor #2 for right-of laptop screen
4. Unplug second monitor and re-plug the first one

Actual Results:  
The monitor #1 screen is configured for right-of laptop screen, instead of same-as as had been configured before

Expected Results:  
Monitor #1 configuration is restored back to what it was (same-as)
Comment 1 Martin Kostolný 2015-11-03 07:06:25 UTC
I'm having the same issue.
Plasma 5.4.2, KF 5.15, Qt 5.5.1, Intel graphics.
Comment 2 Martin Kostolný 2015-12-22 10:20:39 UTC
I think this is fixed for Plasma 5.5.1, KF 5.17.
@Thiago Macieira: can you confirm that?
Comment 3 Thiago Macieira 2015-12-22 16:37:40 UTC
(In reply to Martin Kostolný from comment #2)
> I think this is fixed for Plasma 5.5.1, KF 5.17.
> @Thiago Macieira: can you confirm that?

Will answer when 5.5.1 drops in OpenSUSE Tumbleweed (currently 5.4.3).
Comment 4 Maciej Mrozowski 2015-12-24 01:21:12 UTC
Remember multi-monitor config is minor problem here, detecting screens whenever they change is more pressing. kscreen somewhat cannot catch up with output device hot-plug events. I noticed runnig 'xrandr' tool (without arguments, just in console) actally triggers kscreen to get notified about monitors being reconnected (otherwise hot-plug events seem to be ignored in my case). I heard someone blaming Qt for that..
Comment 5 Maciej Mrozowski 2015-12-24 01:30:24 UTC
Duplicate of  346961 likely.
Comment 6 Thiago Macieira 2015-12-24 01:37:20 UTC
(In reply to Maciej Mrozowski from comment #4)
> Remember multi-monitor config is minor problem here, detecting screens
> whenever they change is more pressing. kscreen somewhat cannot catch up with
> output device hot-plug events. I noticed runnig 'xrandr' tool (without
> arguments, just in console) actally triggers kscreen to get notified about
> monitors being reconnected (otherwise hot-plug events seem to be ignored in
> my case). I heard someone blaming Qt for that..

That used to happen with KDE 4 kscreen too and is not its fault. Running xrandr without arguments causes the video driver (i915, usually) to re-scan the outputs and thus find that you've connected something. It shouldn't be and isn't needed. It's not kscreen's fault and it should not cause frequent polling.
Comment 7 Maciej Mrozowski 2015-12-26 20:30:28 UTC
Then KDE4 kscreen must have had some own randr polling mechanism, because there, it detects my dock-station/monitor hot-plug events immediately. It's just with KDE5 kscreen I have those output detection problems:
https://bugs.kde.org/show_bug.cgi?id=340120
https://bugs.kde.org/show_bug.cgi?id=356505
https://bugs.kde.org/show_bug.cgi?id=351025
https://bugs.kde.org/show_bug.cgi?id=346535
Comment 8 Maciej Mrozowski 2015-12-26 20:43:17 UTC
But that's of course not relevant in this bug. I can also confirm behaviour reported here - not restoring latest monitor configuration.
(in previous comments just wanted say that imho root cause is with not working autodetection, like in the case of bugs where user cannot change monitor resolution occasionally because kscreen has outdated/mismatching EDID information on monitor (like list of supported resolutions), I suspect this might be the case with automatically trying to apply previous config as well)
Comment 9 Thiago Macieira 2016-01-07 17:11:07 UTC
(In reply to Martin Kostolný from comment #2)
> I think this is fixed for Plasma 5.5.1, KF 5.17.
> @Thiago Macieira: can you confirm that?

I *cannot* confirm the fix on 5.5.1.
Comment 10 Thiago Macieira 2016-01-07 17:11:49 UTC
To be clear: kscreen remembers the configuration. It just never applies what it knows when the known monitors are connected.
Comment 11 Thiago Macieira 2016-04-25 17:34:36 UTC
Repeating: kscreen remembers the configuration but fails to apply it

[338791.653] kded5(1707 1707): kscreen: starting external backend launcher for ""
[338791.721] kded5(1707 1707): kscreen.kded:    resetDisplaySwitch()
[338791.721] kded5(1707 1707): kscreen.kded:    outputConnectedChanged(): "HDMI1"
[338791.721] kded5(1707 1707): kscreen.kded:    Calculating config ID for KScreen::Config(0x194cfc0)
[338791.721] kded5(1707 1707): kscreen.kded:            Part of the Id:  "8f1a4a6b5eec2d11cb59060b47b3610a"
[338791.721] kded5(1707 1707): kscreen.kded:            Part of the Id:  "181be8d8ae9f70f1d85e8defd31b0fe6"
[338791.721] kded5(1707 1707): kscreen.kded:            Config ID: "bfb8a9b9e97ddc88f50a9be628232c7e"
[338791.721] kded5(1707 1707): kscreen.kded:    Change detected
[338791.732] kded5(1707 1707): kscreen.kded:    Applying config
[338791.732] kded5(1707 1707): kscreen.kded:    Calculating config ID for KScreen::Config(0x194cfc0)
[338791.732] kded5(1707 1707): kscreen.kded:            Part of the Id:  "8f1a4a6b5eec2d11cb59060b47b3610a"
[338791.732] kded5(1707 1707): kscreen.kded:            Part of the Id:  "181be8d8ae9f70f1d85e8defd31b0fe6"
[338791.732] kded5(1707 1707): kscreen.kded:            Config ID: "bfb8a9b9e97ddc88f50a9be628232c7e"
[338791.732] kded5(1707 1707): kscreen.kded:    Calculating config ID for KScreen::Config(0x194cfc0)
[338791.732] kded5(1707 1707): kscreen.kded:            Part of the Id:  "8f1a4a6b5eec2d11cb59060b47b3610a"
[338791.732] kded5(1707 1707): kscreen.kded:            Part of the Id:  "181be8d8ae9f70f1d85e8defd31b0fe6"
[338791.732] kded5(1707 1707): kscreen.kded:            Config ID: "bfb8a9b9e97ddc88f50a9be628232c7e"
[338791.732] kded5(1707 1707): kscreen.kded:    Applying known config "bfb8a9b9e97ddc88f50a9be628232c7e"
[338791.732] kded5(1707 1707): kscreen.kded:    Finding a mode for QSize(1920, 1080) @ 60.001
[338791.732] kded5(1707 1707): kscreen.kded:            Found:  "72"   QSize(1920, 1080) @ 60.001
[338791.733] kded5(1707 1707): kscreen.kded:    Finding a mode for QSize(1920, 1080) @ 60
[338791.733] kded5(1707 1707): kscreen.kded:            Found:  "384"   QSize(1920, 1080) @ 60
[338791.733] kded5(1707 1707): kscreen.kded:    doApplyConfig()
[338791.733] kded5(1707 1707): kscreen.kded:    Monitor for changes:  false

It says it applied the config, but the screen configuration did not change.
Comment 12 Thiago Macieira 2016-04-26 07:28:53 UTC
Actually, I just noticed that I misdiagnosed the problem.

The problem is that kscreen5 keeps a single configuration file for both my 45" Samsung TV and my 23" Samsung monitor. The kded4 module was able to tell the difference.
Comment 13 Jason Tibbitts 2016-09-06 18:21:09 UTC
I just want to note that as of late I've had no issues at all with kscreen restoring my monitor configuration.  I get perfect session restores every time.

I think things improved when Fedora moved to the 5.7 series (from 5.6.5 to 5.7.2).
Comment 14 Sebastian Kügler 2016-10-16 22:36:32 UTC
@Thiago: This may well be fixed with Plasma 5.8, could you check that?

You're saying you only get a single configuration file, this may happen if the EDID information of both monitors is the same (which shouldn't happen, but, you know ... hardware vendors, especially Samsung...). The output of kscreen-console would be interesting (for all monitors).
Comment 15 Andrew Crouthamel 2018-09-26 22:16:18 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 16 Andrew Crouthamel 2018-10-27 03:57:51 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!