Monitor doesn't turn back on after being turned off due to inactivity

ShaiAvr · 2025-04-16 10:36:15

I am new to Arch, and I have a problem with the monitor. I use KDE, and the screen is set to turn off automatically after some time of inactivity, which is normal. The problem is that after the screen goes off, I can't get it back on again. I try to move the mouse or type on the keyboard to wake up the system, and I hear KDE's system sounds, which indicates that the session is active again. The monitor also flashes like it does when picking up a signal. However, after the flash, the monitor tells me it doesn't get any signal and goes back to standby mode. No matter what I do, I can't get the monitor to turn on again. I tried powering the monitor off and on, but it didn't work. I am quite sure the KDE session works fine because if I wait 2 minutes, which is the time it takes the screen to turn off when on the lock screen, and then move the mouse or type the keyboard, I hear the system sounds again, and the screen flashes again like it picked up a signal, except it says it doesn't find a signal and goes back to standby. The only solution is to physically reboot the computer. The hardware I use (taken from KDE info center):

Operating System: Arch Linux
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.12.0
Qt Version: 6.9.0
Kernel Version: 6.14.2-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 28 × Intel® Core™ i7-14700K
Memory: 31.1 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 4070 SUPER
Manufacturer: ASUS

I have the packages `nvidia`, `nvidia-utils`, and `lib32-nvidia-utils` for the graphics drivers. The monitor I use is Samsung Odyssey G65B (2560x1440 240Hz). Any help would be appreciated.

seth · 2025-04-16 19:49:24

Graphics Platform: Wayland

Same issue on plasma/x11?

ShaiAvr · 2025-04-17 07:54:57

I didn't try X11. I prefer to use Wayland as it's newer, and I heard KDE will drop X11 support in the future.

seth · 2025-04-17 08:08:56

But I guess you prefer to know where the problem is so you maybe stand a chance to solve it?

ShaiAvr · 2025-04-17 08:45:47

Sounds fair. I just tested it, and the issue doesn't occur on X11. I also noticed that the waking process is slightly different between the two sessions.

On Wayland, when I move the mouse to wake up the system, the screen flashes like it just turned on, and I hear KDE system sounds that indicate that the session is resumed. However, the screen doesn't pick a signal and tells me it goes back to standby mode, as I described in the original post. I am 99% certain the system did wake up as expected because if I type my user password and press enter, the keyboard lights up, which indicates I got into the desktop; I just can't see it on the screen.
On X11, when I shake the mouse, the screen just wakes up, and I see the lock screen. I can type my password, press enter and log back in. No screen flash and no system sounds. I just get to the lock screen and go on with the session.

From my experience with this monitor, the flashing happens when I turn the monitor on or off. So, if I had to guess what happens, I'd say that Wayland tells the screen to turn off while X11 probably keeps it on, but makes it black. I don't know how Wayland or X11 work, so I am not sure if my guess is helpful or a complete non-sense

seth · 2025-04-17 16:20:36

while X11 probably keeps it on, but makes it black

Unlikely.

xset dpms force off; sleep 5; xset q | grep -iA3 dpms; printf '\a'

On wayland, check "kscreen-doctor > ~/kscreendoctor.log" once you lost the output.
Another interesting aspect would be whether the screen locker is relevant, can you disable the lockscreen and just have the output turn off (unfortunately idk whether or how kwin_wayland can be convinced to trigger this, though it might also be powerdevil that handles that on that platform)

ShaiAvr · 2025-04-17 20:56:33

Can you explain the commands you gave me before I execute them?
What does the command

xset dpms force off; sleep 5; xset q | grep -iA3 dpms; printf '\a'

do, and do I need to run it in a Wayland or X11 session? The name `xset` implies to me that it's X11-specific, but you said to run it on Wayland?
If I run `kscreen-doctor` on Wayland (without running the previous command you gave me, since I am not sure what it does), I get an empty output. However, after reading the man page of `kscreen-doctor`, I found the `-o` flag which shows output, so running `kscreen-doctor -o` gives:

Output: 1 DP-2
        enabled
        connected
        priority 1
        DisplayPort
        Modes:  1:2560x1440@120!  2:2560x1440@240*  3:2560x1440@60  4:1920x1080@240  5:1920x1080@120  6:1920x1080@120  7:1920x1080@60  8:1680x1050@60  9:1600x900@60  10:1280x1024@60  11:1440x900@60  12:1280x800@60  13:1280x720@60  14:1280x720@60  15:1024x768@60  16:800x600@60  17:720x480@60  18:640x480@60
        Geometry: 0,0 2560x1440
        Scale: 1
        Rotation: 1
        Overscan: 0
        Vrr: Automatic
        RgbRange: unknown
        HDR: disabled
        Wide Color Gamut: disabled
        ICC profile: none
        Color profile source: sRGB
        Color power preference: prefer efficiency and performance
        Brightness control: supported, set to 100% and dimming to 100%

I tried to disable the lock screen by going into System Settings -> Security & Privacy -> Screen Locking and setting "Lock screen automatically" to "never". The screen turned off without going into the lock screen first, but the problem remains. Waking up the system causes the screen to flash and to emit KDE sounds, and the screen goes to standby.

seth · 2025-04-17 21:31:21

https://man.archlinux.org/man/extra/xorg-xset/xset.1.en
https://man.archlinux.org/man/core/coreutils/sleep.1.en
https://man.archlinux.org/man/core/grep/grep.1.en
https://man.archlinux.org/man/core/core … rintf.1.en

It's great that you want to understand a command before you type it into a shell, but why would my explanations of that that does be any more trustworthy than the command itself?

but you said to run it on Wayland?

No, kscreen-doctor would be for wayland, the xset test is to check your assumption that X11 doesn't enter DPMS but "probably keeps [the monitor] on, but makes it black"

flag which shows output, so running `kscreen-doctor -o` gives:

Is that after losing the output?
Anyway,

Rotation: 1

is the output rotated and o you get this when *not* rotating the it?
Do you have the same problem when running at 120Hz or 60Hz?

after reading the man page of `kscreen-doctor`

"kscreen-doctor -h"? There doesn't seem to be a manpage for kscreen-doctor (I actually checked for it)

ShaiAvr · 2025-04-17 22:48:14

Yes, I meant `kscreen-doctor -h`, my bad.
What I got is before I lose output. How am I supposed to run this command after I lose the output? I can’t see anything on the screen and the only “solution” is to physically reboot the machine.
If by “output rotated”, you mean the monitor, then no; I have a normal landscape monitor.

seth · 2025-04-18 07:51:03

I was under the impression that you could operate the system blindly and

seth almost wrote:

kscreen-doctor -o > ~/kscreendoctor.log

which would dump the output to ~/kscreendoctor.log for you to pick up after the reboot.
Other options may include a different VT (ctrl+alt+F3) still working and certainly ssh logins.
(In either case you'll likely have to set the DISPlAY and WAYLAND_DISPLAY variables to steer kscreen-doctor to the relevant context.

the only “solution” is to physically reboot the machine

In any event avoid that, you're jeopardizing the filesystem integrity.
If you cannot shutdown from a different VT or ssh, try to frenetically press ctrl+alt+del, the https://wiki.archlinux.org/title/Keyboa … el_(SysRq) or just briefly touch the power button - do not hold it.

ShaiAvr · 2025-04-18 09:07:27

I was under the impression that you could operate the system blindly

I can try, but I don't know if that would work.

In any event avoid that, you're jeopardizing the filesystem integrity.
If you cannot shutdown from a different VT or ssh, try to frenetically press ctrl+alt+del, the https://wiki.archlinux.org/title/Keyboa … el_(SysRq) or just briefly touch the power button - do not hold it.

I believe I tried these options, and none of them worked. I already rebooted physically each time I experienced the issue. Is there something I should do to make sure the file system integrity is ok?

ShaiAvr · 2025-04-18 09:42:06

I managed to run `kscreen -io` blindly after the display was lost (I also found the -i flag, which gives more info). However, the output seems identical to the case where the display works properly:

Environment:
  * KSCREEN_BACKEND           : [not set]
  * KSCREEN_BACKEND_INPROCESS : [not set]
  * KSCREEN_LOGGING           : [not set]
Logging to                : [logging disabled]
Preferred KScreen backend : KSC_KWayland.so
Available KScreen backends:
  * KSC_Fake.so: /usr/lib/qt6/plugins/kf6/kscreen/KSC_Fake.so
  * KSC_KWayland.so: /usr/lib/qt6/plugins/kf6/kscreen/KSC_KWayland.so
  * KSC_QScreen.so: /usr/lib/qt6/plugins/kf6/kscreen/KSC_QScreen.so
  * KSC_XRandR.so: /usr/lib/qt6/plugins/kf6/kscreen/KSC_XRandR.so

Output: 1 DP-2
        enabled
        connected
        priority 1
        DisplayPort
        Modes:  1:2560x1440@120!  2:2560x1440@240*  3:2560x1440@60  4:1920x1080@240  5:1920x1080@120  6:1920x1080@120  7:1920x1080@60  8:1680x1050@60  9:1600x900@60  10:1280x1024@60  11:1440x900@60  12:1280x800@60  13:1280x720@60  14:1280x720@60  15:1024x768@60  16:800x600@60  17:720x480@60  18:640x480@60
        Geometry: 0,0 2560x1440
        Scale: 1
        Rotation: 1
        Overscan: 0
        Vrr: Automatic
        RgbRange: unknown
        HDR: disabled
        Wide Color Gamut: disabled
        ICC profile: none
        Color profile source: sRGB
        Color power preference: prefer efficiency and performance
        Brightness control: supported, set to 100% and dimming to 100%

So it looks like the system thinks that the display works properly, while it's not. I also found that VT does work after losing the display, so I am able to reboot cleanly. Another interesting detail I noticed is that while typing the `kscreen` command blindly (I typed it in the normal desktop session blindly, not in the VT), the system kept making these sounds I hear when I first wake it up. It's like my input is waking up the system again, despite it's already active, just without display output.

ShaiAvr · 2025-04-18 10:18:15

seth wrote:

Do you have the same problem when running at 120Hz or 60Hz?

I tested it on 120Hz, and the problem vanished. When the computer wakes up, the display works, and everything is fine. So the problem only happens on 240Hz with Wayland.

seth · 2025-04-18 13:19:47

Is this actually 240Hz or adaptive sync (gsync, variable refresh)?
https://wiki.archlinux.org/title/Variable_refresh_rate

Does X11 actually run at 240Hz when it works?
("xrandr -q")

If you're not sure about the vrr capacity

xrandr --verbose

should™ list that (and at least the EDID)

ShaiAvr · 2025-04-18 14:16:05

It's an actual 240Hz monitor. I also have "Adaptive sync" set to "automatic". Running "xrandr -q" on X11 shows it also runs at 240Hz.

seth · 2025-04-18 18:56:05

=> https://bugs.kde.org/ - you probably want to compare the actually used modelines ("xrandr -q" will tell on X11, idk how reliable that is on wayland nor how to query kwin for the actual modeline) - might be that the signal is on the edge and the handshake fails because kwin_wayland uses a different modeline or just because the process blocks somewhere too long or because kscreen removes the output (only on wayland)
It's gonna be fun to debug for sure /sarcasm

ShaiAvr · 2025-04-19 10:59:12

I just found another interesting detail: When I lose the display, I can press Ctrl+Alt+F3 to enter the VT, so I can reboot the system. Another thing I didn't realize is that if I go back into the normal session by pressing Ctrl+Alt+F1, the display works as normal. So there is a workaround to this problem of pressing Ctrl+Alt+F3 and then Ctrl+Alt+F1. Does that give any insight to solve the problem?

seth · 2025-04-20 07:22:30

race condition, esp. together w/ the behavioral difference depending on the refresh rate.
What happens if you turn the monitor off and on again after running into the problem?

ShaiAvr · 2025-04-22 09:11:20

I tested it, and the results are weird. The first time I tried to turn the monitor off and back on, it didn't solve the issue, but then I moved my mouse and the screen came back on. The second time I tested it, turning the screen off and on didn't fix anything, even after shaking the mouse. So, I would say it's an inconsistent solution. On the other hand, pressing Ctrl+Alt+F3 to go to VT and then Ctrl+Alt+F1 to return to the desktop session consistently solves the problem.

seth · 2025-04-22 15:30:04

Can you (randomly) /trigger/ the problem by turning the monitor off and on?
But for this kind of race condition (works reliably at 120Hz but fails at 240Hz, switching the framebuffer after the handshake works) you'll have to file a bug upstream since that will be down to some implementation detail that requires intrinsic knowledge of the relevant code.

ShaiAvr · 2025-04-22 16:44:25

File a bug report where? To KDE, Wayland, Nvidia? I don't even know if it's a problem with any of them, and not something specific to my monitor (Samsung Odyssey G65B).

seth · 2025-04-22 16:48:36

seth wrote:

=> https://bugs.kde.org/ - you probably want to compare the actually used modelines ("xrandr -q" will tell on X11, idk how reliable that is on wayland nor how to query kwin for the actual modeline) - might be that the signal is on the edge and the handshake fails because kwin_wayland uses a different modeline or just because the process blocks somewhere too long or because kscreen removes the output (only on wayland)
It's gonna be fun to debug for sure /sarcasm

Since for all we know it's specific to the kwin_wayland compositor, that's there the problem will have to be solved.
That the problem might involve the signal being on the edge or your monitor being extra picky or whatever ultimately doesn't matter.
You know from X11 and the console that the hardware/handshake does principally work - you could try some other wayland compositors, though.

Arch Linux

#1 2025-04-16 10:36:15

Monitor doesn't turn back on after being turned off due to inactivity

#2 2025-04-16 19:49:24

Re: Monitor doesn't turn back on after being turned off due to inactivity

#3 2025-04-17 07:54:57

Re: Monitor doesn't turn back on after being turned off due to inactivity

#4 2025-04-17 08:08:56

Re: Monitor doesn't turn back on after being turned off due to inactivity

#5 2025-04-17 08:45:47

Re: Monitor doesn't turn back on after being turned off due to inactivity

#6 2025-04-17 16:20:36

Re: Monitor doesn't turn back on after being turned off due to inactivity

#7 2025-04-17 20:56:33

Re: Monitor doesn't turn back on after being turned off due to inactivity

#8 2025-04-17 21:31:21

Re: Monitor doesn't turn back on after being turned off due to inactivity

#9 2025-04-17 22:48:14

Re: Monitor doesn't turn back on after being turned off due to inactivity

#10 2025-04-18 07:51:03

Re: Monitor doesn't turn back on after being turned off due to inactivity

#11 2025-04-18 09:07:27

Re: Monitor doesn't turn back on after being turned off due to inactivity

#12 2025-04-18 09:42:06

Re: Monitor doesn't turn back on after being turned off due to inactivity

#13 2025-04-18 10:18:15

Re: Monitor doesn't turn back on after being turned off due to inactivity

#14 2025-04-18 13:19:47

Re: Monitor doesn't turn back on after being turned off due to inactivity

#15 2025-04-18 14:16:05

Re: Monitor doesn't turn back on after being turned off due to inactivity

#16 2025-04-18 18:56:05

Re: Monitor doesn't turn back on after being turned off due to inactivity

#17 2025-04-19 10:59:12

Re: Monitor doesn't turn back on after being turned off due to inactivity

#18 2025-04-20 07:22:30

Re: Monitor doesn't turn back on after being turned off due to inactivity

#19 2025-04-22 09:11:20

Re: Monitor doesn't turn back on after being turned off due to inactivity

#20 2025-04-22 15:30:04

Re: Monitor doesn't turn back on after being turned off due to inactivity

#21 2025-04-22 16:44:25

Re: Monitor doesn't turn back on after being turned off due to inactivity

#22 2025-04-22 16:48:36

Re: Monitor doesn't turn back on after being turned off due to inactivity

Board footer