Bug 362058 - Dual monitor loses settings after screen sleep
Summary: Dual monitor loses settings after screen sleep
Status: RESOLVED WORKSFORME
Alias: None
Product: KScreen
Classification: Plasma
Component: common (show other bugs)
Version: 5.26.3
Platform: Fedora RPMs All
: NOR normal
Target Milestone: ---
Assignee: Sebastian Kügler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-22 01:41 UTC by Rich Johnson
Modified: 2022-11-21 23:17 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:

Attachments
My /var/log/Xorg.0.log immediately after wakeup (56.24 KB, text/x-log)
2022-05-09 18:48 UTC, Natalie Clarius 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Johnson 2016-04-22 01:41:06 UTC 
If I leave my computer until the desktop locks & then the screen goes black, when I log back in I still have dual monitors. however my config isn't used. It goes to using laptop display as main display & HDMI as a secondary display. Weird thing is, it does use the screen positioning portion of the config & the resolution, just moves bar to other screen & HDMI screen is just black. This happens every time, so yes it is reproducible.

Reproducible: Always

Steps to Reproduce:
1. Let screen lock & go black (aka sleep)
2. Move mouse to wake screen up
3. Log in to unlock desktop

Actual Results:  
HDMI is no longer primary, laptop screen becomes primary. HDMI screen doesn't have desktop background settings nor panel, nor right click functions.

Expected Results:  
My display settings should be used where HDMI is primary & laptop is secondary. Plasma panel should be on the HDMI screen & not the laptop screen.

My current work around is after unlocking the desktop log out & log back in. Everything goes back to normal until the next time the screen goes to sleep.
Comment 1 Martin Flöser 2016-07-20 13:49:46 UTC 
this sounds like your XServer "loses" the output - which should not happen on power management. Could you please check whether that's the case in e.g. /var/log/Xorg.0.log?
Comment 2 Matthew Barnes 2020-10-10 12:41:18 UTC 
I am experiencing this issue also.  Looking at the Xorg.0.log I am seeing the screen disconnect .


[ 71289.913] (--) NVIDIA(GPU-0): DFP-4: disconnected
[ 71289.913] (--) NVIDIA(GPU-0): DFP-4: Internal DisplayPort
[ 71289.913] (--) NVIDIA(GPU-0): DFP-4: 1440.0 MHz maximum pixel clock
[ 71289.913] (--) NVIDIA(GPU-0): 
[ 71289.927] (--) NVIDIA(GPU-0): DFP-6: disconnected
[ 71289.927] (--) NVIDIA(GPU-0): DFP-6: Internal DisplayPort
[ 71289.927] (--) NVIDIA(GPU-0): DFP-6: 1440.0 MHz maximum pixel clock
[ 71289.927] (--) NVIDIA(GPU-0): 
[ 71290.640] (--) NVIDIA(GPU-0): Acer KG281K (DFP-4): connected
[ 71290.640] (--) NVIDIA(GPU-0): Acer KG281K (DFP-4): Internal DisplayPort
[ 71290.640] (--) NVIDIA(GPU-0): Acer KG281K (DFP-4): 1440.0 MHz maximum pixel clock
[ 71290.640] (--) NVIDIA(GPU-0): 
[ 71290.649] (--) NVIDIA(GPU-0): Acer KG281K (DFP-6): connected
[ 71290.649] (--) NVIDIA(GPU-0): Acer KG281K (DFP-6): Internal DisplayPort
[ 71290.649] (--) NVIDIA(GPU-0): Acer KG281K (DFP-6): 1440.0 MHz maximum pixel clock
[ 71290.649] (--) NVIDIA(GPU-0): 
[ 71290.798] (II) NVIDIA(0): Setting mode "DP-4: nvidia-auto-select @3840x2160 +3840+0 {ViewPortIn=3840x2160, ViewPortOut=3840x2160+0+0}"
[ 71290.937] (II) NVIDIA(0): Setting mode "NULL"
[ 71291.089] (II) NVIDIA(0): Setting mode "DP-2: nvidia-auto-select @3840x2160 +0+0 {ViewPortIn=3840x2160, ViewPortOut=3840x2160+0+0}"
[ 71291.141] (II) NVIDIA(0): Setting mode "DP-2: nvidia-auto-select @3840x2160 +0+0 {ViewPortIn=3840x2160, ViewPortOut=3840x2160+0+0}, DP-4: nvidia-auto-select @3840x2160 +3840+0 {ViewPortIn=3840x2160, ViewPortOut=3840x2160+0+0}"
Comment 3 Jacek Wieczorek 2021-07-16 16:43:48 UTC 
I think I'm experiencing this bug too. In my case, each broken screen sleep leads to wallpaper change on my secondary monitor, disabling the compositor and sometimes moving certain windows around (usually code-oss).

In my /var/log/Xorg.0.log I can see the the screens disconnecting, exactly as Matthew Barnes said.

My testing consisted of logging output of `xrandr` in 0.1s intervals throughout different sleep cycles. I set "Switch off screens after" to 1 minute in system settings and then woke up the screens after different periods of time. I found out that if I wake up my computer after 3 or less minutes (including 1 min of waiting for the screens to switch off), it always wakes up correctly. 

Correct screen wake up after 3 min - everything is fine:
   1562 DP-2 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
   1562 DP-4 connected primary 2560x1440+2560+0 (normal left inverted right x axis y axis) 597mm x 336mm

Broken wake up after 4 min - monitors temporarily disconnect, compositor is disabled, wallpapers change, windows are moved around (for DP-4):
   2027 DP-4 connected primary 2560x1440+2560+0 (normal left inverted right x axis y axis) 597mm x 336mm
      7 DP-4 disconnected primary 2560x1440+2560+0 (normal left inverted right x axis y axis) 0mm x 0mm
      8 DP-4 disconnected (normal left inverted right x axis y axis)
      7 DP-4 connected (normal left inverted right x axis y axis)
     54 DP-4 connected primary 2560x1440+2560+0 (normal left inverted right x axis y axis) 597mm x 336mm

Interestingly, when kscreen is not running, the behavior doesn't change but the logs look a bit differently.
Broken wake up after 4 min, kscreen not running (for DP-4):
   1982 DP-4 connected primary 2560x1440+2560+0 (normal left inverted right x axis y axis) 597mm x 336mm
     15 DP-4 disconnected primary 2560x1440+2560+0 (normal left inverted right x axis y axis) 0mm x 0mm
     76 DP-4 connected primary 2560x1440+2560+0 (normal left inverted right x axis y axis) 600mm x 340mm

I uploaded the compressed logs to this Github repo: https://github.com/Jacajack/logs/tree/master/dual-monitor. I use `xzcat log.txt.xz | grep 'DP-2' | uniq -c` to read them.

Some other observations:
 - "Broken" wake up always takes visibly more time than a normal one
 - I can reproduce this behavior on fresh Manjaro Live with or without Nvidia driver
 - Enabling/disabling DPMS doesn't change anything
 - It doesn't matter whether the lockscreen appears
 - "Auto input switch", "Automatic Standby" and "Smart Energy Saving" in screens' OSD menus don't affect this behavior

Given that XFCE users report similar behavior and that kscreen is not necessary for this bug to happen, maybe X.Org is in fact the problem? Maybe we should think of filing a bug report there?

System info:
  Manjaro Linux, kernel 5.10.49
  plasmashell version: 5.22.3
  xorg version: 1.20.11
  GPU: Nvidia RTX 2070 SUPER
  Nvidia driver version: 470.42.01
  Monitors: 2 x LG Ultragear 27GL850 connected via Display Port
Comment 4 Natalie Clarius 2022-05-09 18:48:00 UTC 
I'm getting the same on 5.24 X11, but with the configuration being changed from extend to unify. The laptop is my primary screen and on the left, and the external HDMI monitor is secondary and set to be an extension to the right. After sleep my laptop screen shows what was previously on only on my secondary monitor, more precisely the topleft section of it because my laptop screen is smaller in resolution but the contents are not refitted.
Comment 5 Natalie Clarius 2022-05-09 18:48:49 UTC 
Created attachment 148688 [details]
My /var/log/Xorg.0.log immediately after wakeup
Comment 6 r0y 2022-08-21 16:31:56 UTC 
I believe I am experiencing this on Kubuntu 22.04 LTS (since installing in Apr 2022, and through various updates).  If it is a short sleep, no issues.  If it is longer than a few minutes, the secondary monitor "forgets" the wallpaper and sets the default one.
My main monitor is a 2K via DP, secondary is a FHD via HDMI.  It is a custom-built PC (desktop, mid-tower).  Apologies for the "below tech" addition here, just wanted to add Kubuntu 22.04 into the mix.  DM is in a dark theme, but I've set the wallpapers in both dark and light themes, and still experience this.
Comment 7 ProstMeister 2022-10-27 06:53:09 UTC 
It also happens in KDE 5.26.2, running an XOrg session, and also after rebooting, on top of wakeup after sleep.
Each time I fire up my laptop, I have to set-up again my 3-monitor settings. 
This is happening since Plasma 5.26.0 has been released.
Every time I do this, a new config file is created within ~/.local/share/kscreen/. I can post any of them, if needed. 
The various config files created every time are identical (just compared 2 of them with Kompare).
It seems that kscreen just ignores any previously created config file and keeps creating a new one every time you change your screens settings.
Comment 8 ProstMeister 2022-10-27 06:53:54 UTC 
(In reply to ProstMeister from comment #7)
> It also happens in KDE 5.26.2, running an XOrg session, and also after
> rebooting, on top of wakeup after sleep.
> Each time I fire up my laptop, I have to set-up again my 3-monitor settings. 
> This is happening since Plasma 5.26.0 has been released.
> Every time I do this, a new config file is created within
> ~/.local/share/kscreen/. I can post any of them, if needed. 
> The various config files created every time are identical (just compared 2
> of them with Kompare).
> It seems that kscreen just ignores any previously created config file and
> keeps creating a new one every time you change your screens settings.

I forgot to tell you that I'm running on EndeavourOS.
Comment 9 Nate Graham 2022-11-10 18:11:29 UTC 
Unfortunately each of you who are experiencing this issue could easily be experiencing it for a completely different reason. Multimonitor bugs are weird like that.

Can I ask each of you to file a new bug report, and paste the output of `kscreen-doctor -o` before and after sleep? Thanks! Also please mention what GPU hardware you're using.

As for this bug, the original reporter never responded, so it's not actionable for the specific issue he was reporting and we have to close it. Everyone else, please do file your own bug reports. Thanks a lot!
Comment 10 r0ck3r 2022-11-17 13:31:45 UTC Comment hidden (spam)
Comment 11 r0ck3r 2022-11-17 13:32:47 UTC Comment hidden (spam)
Comment 12 r0ck3r 2022-11-17 13:33:52 UTC Comment hidden (spam)
Comment 13 r0ck3r 2022-11-17 13:43:46 UTC Comment hidden (spam)
Comment 14 Nate Graham 2022-11-18 16:59:13 UTC Comment hidden (spam)
Comment 15 ProstMeister 2022-11-19 17:08:30 UTC Comment hidden (spam)
Comment 16 Nate Graham 2022-11-21 22:39:48 UTC Comment hidden (spam)