[SOLVED] monitor not staying asleep

nixIT · 2021-12-25 20:01:35

hello all, and happy holidays.

I recently received a 2k monitor, excellent resolution, however when my power management settings kick in, the monitor comes right back on.

It's s spectre monitor, connected via digital cable, and used the same cable that I had my 1080p monitor on. every other monitor I have owned has always gone to sleep specified by the time in power management, and have stayed asleep, just not this one.

I am running XFCE, nvidia GTX 960 with latest drivers, and under settings manager/power management/display I have:

blank after 5 minutes
put sleep after 10
switch off after 30

the monitor blanks at 1 minute, when a window pops up saying I lost signal and to check the cable, it goes away and another window pops up with a message saying the monitor is going to sleep, but then the monitor wakes up. it never stays off. I've never seen this with any other monitor I had.

I tried hard coding DPMS settings in an XORG file, that didn't help.

any idea what to look for?

thanx

~nixit

TLDR;
returned the monitor.

Last edited by nixIT (2021-12-27 03:37:19)

seth · 2021-12-25 22:06:15

/usr/share/doc/nvidia/README wrote:

Q. My displays are reconfigured in unexpected ways when I plug in or unplug a display, or power a display off and then power it on again.
A. This is a special case of the issues described in "Q. The display settings I configured in nvidia-settings do not persist." in Chapter 8. Some desktop environments which include advanced display configuration tools will automatically configure the display layout in response to detected configuration changes. For example, when a new display is plugged in, such a desktop environment may attempt to restore the previous layout that was used with the set of currently connected displays, or may configure a default layout based upon its own policy.
On X servers with support for RandR 1.2 or later, the NVIDIA X driver reports display hotplug events to the X server via RandR when displays are connected and disconnected. These hotplug events may trigger a desktop environment with advanced display management capabilities to change the display configuration. These changes may affect settings such as the set of active displays, their resolutions and positioning relative to each other, per-display color correction settings, and more.
In addition to hotplug events generated by connecting or disconnecting displays, DisplayPort displays will generate a hot unplug event when they power off, and a hotplug event when they power on, even if no physical plugging in or unplugging takes place. This can lead to hotplug-induced display configuration changes without any actual hotplug action taking place.
Upon suspend, the NVIDIA X driver will incur an implicit VT switch. If a DisplayPort monitor is powered off when a VT switch or modeset occurs, RandR will forget the configuration of that monitor. As a result, the display will be left without a mode once powered back on. In the absence of an RandR-aware window manager, bringing back the display will require manually configuring it with RandR.
If display hotplug events are resulting in undesired configuration changes, try the solutions and workarounds listed in "Q. The display settings I configured in nvidia-settings do not persist." in Chapter 8. Another workaround would be to disable the NVIDIA X driver's reporting of hotplug events with the "UseHotplugEvents" X configuration option. Note that this option will have no effect on DisplayPort devices, which must report all hotplug events to ensure proper functionality.
…
Option "UseHotplugEvents" "boolean"
When this option is enabled, the NVIDIA X driver will generate RandR display changed events when displays are plugged into or unplugged from an NVIDIA GPU. Some desktop environments will listen for these events and dynamically reconfigure the desktop when displays are added or removed.
Disabling this option suppresses the generation of these RandR events for non-DisplayPort displays, i.e., ones connected via VGA, DVI, or HDMI.
Hotplug events cannot be suppressed for displays connected via DisplayPort.
Note that probing the display configuration (e.g. with xrandr or nvidia-settings) may cause RandR display changed events to be generated, regardless of whether this option is enabled or disabled. Additionally, some VGA ports are incapable of hotplug detection: on such ports, the addition or removal of displays can only be detected by re-probing the display configuration.
Default: on. The driver will generate RandR events when displays are added or removed.

yochananmarqos · 2021-12-25 22:09:48

@seth: That's normally helpful information, however in this case none of that applies. Reports like this have been coming in everywhere recently. It seems it may be a kernel or Xorg issue since it doesn't seem to matter what DE / WM folks are using.

seth · 2021-12-25 22:25:57

none of that applies

The OP only states a "digital cable" which could be HDMI, DP or DVI.
A theoretic cause would be that the monitor goes to sleep, unregisters, causes a hotplug event, causes a reconfiguration down the road, causes a randr poll causes the monitor to wake.

Reports like this have been coming in everywhere recently.

Links? Also the OP specifically stated this happend with a monitor change.

nixIT · 2021-12-25 22:29:21

yochananmarqos wrote:

@seth: That's normally helpful information, however in this case none of that applies. Reports like this have been coming in everywhere recently. It seems it may be a kernel or Xorg issue since it doesn't seem to matter what DE / WM folks are using.

thanx for the response, and you're correct, this doesn't apply to me. I am using a DigitalPort, not HDMI or DVI. and my previous monitor, connected with same cable, would honor the power management sleep settings and go to sleep and stay asleep, so it appears this may be monitor specific.

I am currently going down the rabbit hole of many more xorg.conf settings that I've never had to set to see if this works.

will report back in a few.

~nixit

seth · 2021-12-25 22:32:49

"DisplayPort" - what monitor (vendor/model) is that exactly?

yochananmarqos · 2021-12-25 22:43:12

seth wrote:

Links?

Sorry, was trying to remember where I saw similar reports. Found a few:

https://gitlab.gnome.org/GNOME/gnome-se … issues/609

https://gitlab.gnome.org/GNOME/gnome-sh … ssues/4773

seth wrote:

A theoretic cause would be that the monitor goes to sleep, unregisters, causes a hotplug event, causes a reconfiguration down the road, causes a randr poll causes the monitor to wake.

Right, that shouldn't be happening.

Graphics:
  Device-1: NVIDIA TU116M [GeForce GTX 1660 Ti Mobile] vendor: CLEVO/KAPOK
    driver: nvidia v: 495.46 alternate: nouveau,nvidia_drm bus-ID: 07:00.0
    chip-ID: 10de:2191 class-ID: 0300
  Device-2: Logitech Webcam C270 type: USB driver: snd-usb-audio,uvcvideo
    bus-ID: 1-1.3:6 chip-ID: 046d:0825 class-ID: 0102 serial: <filter>
  Device-3: Chicony Chicony USB2.0 Camera type: USB driver: uvcvideo
    bus-ID: 5-4:2 chip-ID: 04f2:b685 class-ID: 0e02
  Display: x11 server: X.Org 1.21.1.2 compositor: gnome-shell v: 41.2
    driver: loaded: nvidia display-ID: :1 screens: 1
  Screen-1: 0 s-res: 5760x1080 s-dpi: 92 s-size: 1590x301mm (62.6x11.9")
    s-diag: 1618mm (63.7")
  Monitor-1: DP-0 res: 1920x1080 dpi: 93 size: 527x297mm (20.7x11.7")
    diag: 605mm (23.8")
  Monitor-2: DP-2 res: 1920x1080 hz: 144 dpi: 142
    size: 344x194mm (13.5x7.6") diag: 395mm (15.5")
  Monitor-3: DP-3 res: 1920x1080 dpi: 93 size: 527x297mm (20.7x11.7")
    diag: 605mm (23.8")
  OpenGL: renderer: NVIDIA GeForce GTX 1660 Ti/PCIe/SSE2
    v: 4.6.0 NVIDIA 495.46 direct render: Yes

Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): DFP-0: disconnected
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): DFP-0: Internal DisplayPort
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): DFP-0: 2660.0 MHz maximum pixel clock
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0):
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): DFP-0: disconnected
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): DFP-0: Internal DisplayPort
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): DFP-0: 2660.0 MHz maximum pixel clock
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0):
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): DFP-1: disconnected
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): DFP-1: Internal TMDS
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): DFP-1: 165.0 MHz maximum pixel clock
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0):
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): DFP-2: disconnected
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): DFP-2: Internal TMDS
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): DFP-2: 165.0 MHz maximum pixel clock
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0):
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): NCP (DFP-3): connected
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): NCP (DFP-3): Internal DisplayPort
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): NCP (DFP-3): 2660.0 MHz maximum pixel clock
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0):
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): HPN HP X24ih (DFP-4): connected
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): HPN HP X24ih (DFP-4): Internal DisplayPort
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): HPN HP X24ih (DFP-4): 2660.0 MHz maximum pixel clock
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0):
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): DFP-5: disconnected
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): DFP-5: Internal TMDS
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0): DFP-5: 165.0 MHz maximum pixel clock
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (--) NVIDIA(GPU-0):
Dec 23 22:24:17 serval /usr/lib/gdm-x-session[2348]: (II) NVIDIA(0): Setting mode "DP-3: 1920x1080_144 @1920x1080 +0+0 {AllowGSYNCCompatible=On, ViewPortIn=1920x1080, ViewPortOut=1920x1080+0+0}"

Last edited by yochananmarqos (2021-12-25 22:46:45)

seth · 2021-12-25 22:53:34

Is the journal from your system?

This can possibly be narrowed down by simplifying the system - remove GDM (second display server isn't helpful) and "startx xterm" and in the xterm "xset dpms force standby", "xset dpms force suspend" and "xset dpms force off" and see whether any of the DPMS modes (or all) prevail.

nixIT · 2021-12-25 22:54:20

seth wrote:

"DisplayPort" - what monitor (vendor/model) is that exactly?

sceptre e275b-qpt168

https://www.amazon.com/Sceptre-DisplayP … 166&sr=8-2

yochananmarqos · 2021-12-25 22:59:36

seth wrote:

Is the journal from your system?

Yep.

seth wrote:

remove GDM

Why would I do that? I'm using GNOME.

seth wrote:

second display server

Who's on first?

I'll test those different xset commands, that's a great idea

@nixIT: I had no intention of hijacking your thread, but hopefully all this helps you as well.

Last edited by yochananmarqos (2021-12-26 03:54:42)

seth · 2021-12-25 23:04:50

@nixIT, there's a suspicious "sleep mode" option in the "system" section of the OSD. You could try whether it has any impact.
@yochananmarqos

Why would I do that?

because

Who's on first?

is GDM…
It runs your (gnome or other) session on a second display server while GDM maintains the first one - in doubt even on a wayland session, what will complicate things even more.
So disable GDM and startx from the console to create a more controlled environment.

nixIT · 2021-12-25 23:06:09

I tried the hardDPMS setting in xorg, that didn't help.

thank you all for the help, I think I'm just going to return the 2k monitor since this does not work as easily as it should.

nixIT · 2021-12-25 23:07:58

seth wrote:

@nixIT, there's a suspicious "sleep mode" option in the "system" section of the OSD. You could try whether it has any impact.
@yochananmarqos
Why would I do that?
because
Who's on first?
is GDM…
It runs your (gnome or other) session on a second display server while GDM maintains the first one - in doubt even on a wayland session, what will complicate things even more.
So disable GDM and startx from the console to create a more controlled environment.

@seth,

thanx, I checked that, and that didn't even help, the monitor would turn back on once in sleep mode. this is an odd one.

nixIT · 2021-12-25 23:09:26

yochananmarqos wrote:

...
@nixIT: I had no intention of hijacking your post, but hopefully all this helps you as well.

no problem @yochananmarqos, if this post can help someone, it's all good. I'm glad you're getting useful info from it as well.

yochananmarqos · 2021-12-25 23:18:14

seth wrote:

GDM...runs your (gnome or other) session on a second display server while GDM maintains the first one.

No, Who's on first, What's on second.

GDM does the thing while the other GDM does the other thing? Huh?

seth wrote:

disable GDM and startx from the console to create a more controlled environment.

Ah, that's what you were getting at.

nixT wrote:

I think I'm just going to return the 2k monitor

That's a bit extreme. I don't think the issue is with the monitor itself.

nixIT · 2021-12-25 23:37:16

yochananmarqos wrote:

nixT wrote:
I think I'm just going to return the 2k monitor
That's a bit extreme. I don't think the issue is with the monitor itself.

the 1080p monitor works and this has challenges, don't see that as extreme. I always knew one was going back, and this just made the job of picking easier.

I do like the 2k, so I am giving it until sunday night, if I can't get it working, the sceptre 2k drew the short straw.

I'll still take all the troubleshooting help I get, b/c the 2k makes audio and video editing WAYYY easier.

~nixit

karabaja4 · 2021-12-26 00:29:20

I had a fair share of monitor DPMS breakages with kernel updates every so often.

Eventually I got very annoyed by it breaking, and I decided to just kill it and have a cron job control my monitor power:

#!/bin/sh
set -eu

xset -display :0.0 dpms 0 0 0

if ! grep -q "RUNNING" /proc/asound/card*/pcm*/sub*/status # is ALSA playing sounds?
then
    if [ "$(DISPLAY=:0 xprintidle)" -gt 300000 ] # 5 min = 300000 ms
    then
        xset -display :0.0 dpms force off
    fi
fi

*/5 * * * *    /home/user/scripts/dpms.sh

Is something like that an option for you?

nixIT · 2021-12-26 03:48:37

seth wrote:

Is the journal from your system?
This can possibly be narrowed down by simplifying the system - remove GDM (second display server isn't helpful) and "startx xterm" and in the xterm "xset dpms force standby", "xset dpms force suspend" and "xset dpms force off" and see whether any of the DPMS modes (or all) prevail.

I tried these commands, at least I think they worked.

xset dpms force standby
--the monitor blanked for a second or two and came back

xset dpms force suspend
--the monitor blanked for a second or two and came back

xset dpms force off
--the monitor blanked, then the following
----- a sceptre window came up saying there is no signal and check cables, went away,
----- another sceptre window saying no signal and the monitor is going to sleep

and then they kept alternating repeating, like the monitor is "looking for a signal"??

nixIT · 2021-12-26 03:54:31

@karabaja4,

I honestly think it's a monitor thing.

when I xset dpms force off from a terminal, the monitor went off, and then the spectre window saying so signal and to check input came up, then another window saying it's going into power saving mode.

then I just noticed the blue LED power light turned off and then back on, then the monitor turned on.

I'm waiting for their support to open to see if I can call in.

~nixit

seth · 2021-12-26 08:51:43

Because of #17
Does any of you use DP audio? (Ie. the crappy speakers built into a monitor that make ACDC sound like Britney Spears?)

If not, try to simply blacklist snd_hda_codec_hdmi, https://wiki.archlinux.org/title/Kernel … acklisting - the /bin/true approach is the broadsword, in case the module gets explicitly loaded somewhere.
The amdgpu and radeon modules also have an "amdgpu.audio=0" parameter.

nixIT · 2021-12-26 17:38:27

seth wrote:

Because of #17
Does any of you use DP audio? (Ie. the crappy speakers built into a monitor that make ACDC sound like Britney Spears?)
If not, try to simply blacklist snd_hda_codec_hdmi, https://wiki.archlinux.org/title/Kernel … acklisting - the /bin/true approach is the broadsword, in case the module gets explicitly loaded somewhere.
The amdgpu and radeon modules also have an "amdgpu.audio=0" parameter.

@seth,

thanx for all your help during this craziness...

I'm familiar with blacklisting, not sure what you mean by "because of #17".

seth · 2021-12-26 17:40:59

The script in post #17 is sound aware what gave me the idea that some sound signals rather than video might wake the output.

nixIT · 2021-12-26 17:47:14

seth wrote:

The script in post #17 is sound aware what gave me the idea that some sound signals rather than video might wake the output.

gotcha... thanx.

I just implemented your blacklist suggestion, now awaiting for it to sleep.

EDIT: nope, didn't work for me. monitor is getting packed up and going back.

appreciate all your help, just going to save a little more and buy an MSI 27" 2k monitor.

Last edited by nixIT (2021-12-26 17:51:06)

nachopro · 2023-12-15 17:55:31

Hello, I was reading this entry because I'm facing the same issue.

I have two Asus ProArt Display PA248QV. I used it with an Intel based laptop (igpu) running Ubuntu with out problems (one via DisplayPort and the other with HDMI).

Yesterday I put together my new AMD-based computer and installed Arch+XFCE using both displays via HDMI.

I can't sleep them nor use only one of them: Every times that displays poweroff, it start to search a new image source until the HDMI is found and then wakeup.

I started the PC with a Live Ubuntu and got the same behavior.
Is maybe it related to the AMD iGPU? because with Intel iGPU was fine.

Any idea?

Thank you!

PD1:
My build: Gigabyte A520I AC + AMD Ryzen 5 5600G with Radeon Graphics

Arch Linux

#1 2021-12-25 20:01:35

[SOLVED] monitor not staying asleep

#2 2021-12-25 22:06:15

Re: [SOLVED] monitor not staying asleep

#3 2021-12-25 22:09:48

Re: [SOLVED] monitor not staying asleep

#4 2021-12-25 22:25:57

Re: [SOLVED] monitor not staying asleep

#5 2021-12-25 22:29:21

Re: [SOLVED] monitor not staying asleep

#6 2021-12-25 22:32:49

Re: [SOLVED] monitor not staying asleep

#7 2021-12-25 22:43:12

Re: [SOLVED] monitor not staying asleep

#8 2021-12-25 22:53:34

Re: [SOLVED] monitor not staying asleep

#9 2021-12-25 22:54:20

Re: [SOLVED] monitor not staying asleep

#10 2021-12-25 22:59:36

Re: [SOLVED] monitor not staying asleep

#11 2021-12-25 23:04:50

Re: [SOLVED] monitor not staying asleep

#12 2021-12-25 23:06:09

Re: [SOLVED] monitor not staying asleep

#13 2021-12-25 23:07:58

Re: [SOLVED] monitor not staying asleep

#14 2021-12-25 23:09:26

Re: [SOLVED] monitor not staying asleep

#15 2021-12-25 23:18:14

Re: [SOLVED] monitor not staying asleep

#16 2021-12-25 23:37:16

Re: [SOLVED] monitor not staying asleep

#17 2021-12-26 00:29:20

Re: [SOLVED] monitor not staying asleep

#18 2021-12-26 03:48:37

Re: [SOLVED] monitor not staying asleep

#19 2021-12-26 03:54:31

Re: [SOLVED] monitor not staying asleep

#20 2021-12-26 08:51:43

Re: [SOLVED] monitor not staying asleep

#21 2021-12-26 17:38:27

Re: [SOLVED] monitor not staying asleep

#22 2021-12-26 17:40:59

Re: [SOLVED] monitor not staying asleep

#23 2021-12-26 17:47:14

Re: [SOLVED] monitor not staying asleep

#24 2023-12-15 17:55:31

Re: [SOLVED] monitor not staying asleep

Board footer