I am using KDE Plasma with Wayland on CachyOS. I have a weird problem when the screen turns off due to inactivity. I have a Samsung Odyssey G65B monitor running in 2560x1440 resolution and 240Hz refresh rate. When I let the screen turn off due to inactivity, the monitor tells me it doesn’t detect a signal, so it will go to standby mode in 60 seconds, which is normal. After it goes to standby mode, I shake the mouse to wake the system up. The screen flashes, which it usually does when being turned on or off, and I also hear KDE system sounds. However, instead of turning on, the screen tells me it can’t detect a signal, and it goes back to standby mode. Shaking the mouse more causes more system sounds to play, but the screen won’t wake up. I know the system does wake up, since I can blindly type my password to enter the desktop, and the keyboard lights up since its drivers take over. I can also blindly press a shortcut to open a terminal and type a command like sudo reboot now, and the system reboots. After reboot, everything is normal again.
So the system does wake up and the desktop session works, but the screen doesn’t pick up the signal. There are some weird conditions and consequences of this problem, which I am not able to understand.
The problem only happens on Wayland. If I switch to X11 and let the screen turn off and then wake it up, everything works fine. The screen wakes up, and I see the login screen.
The problem only happens on 240Hz. If I change the screen refresh rate to 120Hz or 60Hz, there is no problem. The screen wakes up, and I see the login screen.
Turning the monitor off and on usually doesn’t fix anything, but there was one time it did make the screen wake up. I am not able to reproduce it consistently, though.
If I press Ctrl+Alt+F3 to go to a virtual console, the screen wakes up and goes to the virtual console. Pressing Alt+F2 after that to return to the desktop session fixes the problem, and I see the login screen. This and rebooting are the only consistent workarounds to this problem I found.
My GPU is NVIDIA GeForce RTX 4070 SUPER. At the beginning, I thought it was a bug in KDE, but when I reported it to KDE, they told me it’s definitely a driver bug and I should report it here.
I’m using Xorg with a Samsung-Odyssey-G95SC + GeForce RTX 4060 (AD107-A) on Ubuntu 24.04. Similar issues, so it is probably correct, that this is not a KDE or wayland problem. I guess the Samsung firmware does strange things (assumes to be driven by ms windows bloat) and results in such a bad behavior (which happened in 22.04, too - so probably not an OS issue as well). Basically when the screen saver started, or when logged out [and turned the screen explicitly off] it was impossible to revive the screen. The only way I found to revive it was to restart Xorg (“Option “XKbOptions” “terminate:ctrl_alt_bksp”). I tried different drivers (565, 575, 580) so I tend to blame the monitor firmware. However, what I’ve done is to use the edid binary downloaded from the monitor - which seems to mitigate the problem a little bit (IIRC I re-enabled the screensaver, but not sure. Was a horror, when I left the workplace, came back later and the Xsession was not accessible/usable anymore). Also, because I have lightdm (login manager) running, when I’m coming back to my workplace and the monitor has been switched off, I first type 2-3 letters on the keyboard and after that I power on the monitor. This seems to work for ~ 8/10. The other 2 times I still need to Ctrl+Alt+Backspace (restart Xorg). FWIW I’ll try to attach my /etc/X11/xorg.conf .
Running Arch on Wayland with KDE Plasma and a Samsung C49RG9X. Although my display only maxes at 120hz, it still seems unable to wake with activity nor programmatically over SSH. Have to power cycle it and that makes unattended access with automatic login and lock with RustDesk, or to wake and jump into Sunshine/Moonlight impossible. Annoying, add I updated Samsung firmware to no avail.
I was having the same problem with a 4080 and gnome/wayland and an LG 27GR93U-B, I was able to work around the issue by disabling the LG monitor’s “deep sleep” feature.
The problem has nothing to do with Linux, it happens in Windows as well, at least on my 3070 and 5070 connected to a 1440p 360 HZ monitor.
The culpit is DSC. DP 1.4 or HDMI 2.1 you are using for connection does not provide enough bandwidth for 1440p 360hz uncompressed, so DSC kick in and that is what causing black screens. To resolve it, hot replug the monitor cable or attach another display (I just turn on my IP kvm connected to another port on the GPU). This will reset the monitor setup and you will see the image again.
The maximum you can get on DP1.4 uncompressed is 240hz, what’s why you never experience issue on lower refresh rates, as DSC is not used. On most monitors, you can see if DSC is used or not in OSD.
Same bug here, and I can add a deterministic repro plus confirmation that it’s still present on the brand-new 610.43.02 feature branch (both open and proprietary modules).
System
GPU: RTX 4090
Monitors: 2× Asus PG32UCDM 3840x2160@240 (DisplayPort, DSC-required at this mode; one rotated 90°) + 1× Corsair Xeneon Edge 2560x720@60 (HDMI)
After the displays DPMS power-down (idle blank / screensaver), the compositor cannot bring them back — panels stay dark while the session is alive. gnome-shell logs, on every wake attempt:
Page flip failed: drmModeAtomicCommit: Invalid argument
Failed to post KMS update: drmModeAtomicCommit: Invalid argument
Invalid argument = EINVAL. No NVRM/Xid in the kernel log at failure time — the modeset is being validated and refused, not crashing. A VT switch (DRM master drop/reacquire) does not clear it.
Deterministic repro (no waiting for real idle)
Force a DPMS off→on cycle via Mutter with the DP panels at 240 Hz:
gdbus call --session --dest org.gnome.Mutter.DisplayConfig \
--object-path /org/gnome/Mutter/DisplayConfig \
--method org.freedesktop.DBus.Properties.Set \
org.gnome.Mutter.DisplayConfig PowerSaveMode "<3>" # off; wait ~10s
... PowerSaveMode "<0>" # on -> EINVAL on every commit
Wedges on the first cycle, every time.
Bisection + driver/flavor matrix (all tested on this same hardware)
All four are clean at 120 Hz (0 failures across many forced off/on cycles incl. 30s “deep sleep”). Dropping both DP panels 240→120 Hz is the only thing that reliably fixes it.
Because it reproduces identically across both driver branches and both kernel-module flavors, the fault is in the shared RM/GSP layer (same GSP firmware in all four), not the kernel module — consistent with the DSC-bandwidth-on-wake theory raised above: the 4K@240 panels need DSC, and the multi-head mixed-refresh config (240+240+60) is what fails to re-establish in a single atomic commit after power-down.
I have nvidia-bug-report logs but the forum is just spinning on “processing upload” when I try to attach them. Will try again later. Or I can host them somewhere if that helps.
Following up — for the multi-monitor, multiple-4K@240 variant of this, I traced it to a hardware limit rather than a driver bug, and there’s a compositor-side fix worth knowing about.
The limit (Ada / RTX 40-series specifically): head-bonding is driven by pixel clock, not DSC — when a mode’s pixel clock exceeds what a single display head can process, the GPU bonds two heads. On Ada the per-head ceiling sits between 4K@120 (one head) and 4K@240 (two heads), so each 4K@240 output uses two of the four heads. Two of them consume all four — matching NVIDIA’s “2 displays @ 4K 240Hz” spec — leaving none for a third monitor. (Note this is generation-specific: Blackwell/RTX 50 raised the per-head ceiling enough that 4K@240 fits in a single head, so 2× 4K@240 + a third display fits there.)
Confirmed by per-panel testing (RTX 4090, driver 595 and 610, both open and proprietary modules, GNOME/Mutter Wayland), reading the actual scanout with modetest:
DP-1 240 / DP-2 120 → both engage, no errors
DP-1 120 / DP-2 240 → both engage, no errors
DP-1 240 / DP-2 240 → drmModeAtomicCommit: Invalid argument, one panel forced to 120
So either 4K can do 240 alone; the two simply can’t both do 240 once a third display is attached. The “wedge on wake” is the compositor trying to restore that over-budget config on resume.
The bad part is the UX, and it’s fixable in the compositor: the over-budget config is silently accepted — Mutter (and KDE) report 240 while the panel stays at 120, with no error surfaced, which is what makes this so hard to diagnose. I’ve proposed a fix upstream: Mutter pre-validates a proposed configuration with a TEST_ONLY atomic commit before applying it, so an unsatisfiable config is refused with a clear error (“Changes cannot be applied — hardware limitations”) instead of silently desyncing — GNOME/mutter!5098 (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/5098), tracked as issue #4839.
If your case is a single high-refresh monitor failing to wake, that’s likely a different issue from the head-budget one above.