COSMIC Greeter Delays and Display Power Management Fails to Sleep or Stay Off

[winlinuxmatt]

I’m seeing the same post-wake login delay on Pop!_OS 24.04 with COSMIC, and this is clearly a regression. The behavior was noticeably better on 22.04, and that alone should put this issue on the radar.

There appears to be a DPMS and wake interaction that introduces a 3 to 4 second delay and sometime even a 1-5 minute delay before anything usable appears. If the display wakes and I’m staring at a blank screen for several seconds, that’s a bug, full stop. In some cases, the screen remains blank for minutes, forcing a reboot to recover a usable desktop. I’ve also observed displays powering back on without user activity. This strongly suggests a DPMS issue under Wayland where cosmic-greeter may be mishandling display power events.

What appears to be happening

Based on this report and similar feedback, the greeter often takes multiple seconds to appear after user activity, even when suspend is disabled and only screen blanking is enabled. Older Pop!_OS releases did not behave this way. The greeter appeared immediately when the display woke. Something in the new stack is therefore slower, more fragile, or both.

Historically, DPMS comes from X11. Commands like xset dpms force off instructed the X server to power down the monitor after idle. Under Wayland, this model no longer applies. There is no X-style DPMS API. Compositors control display power directly and expose only the functionality they choose to support. As a result:

X11 DPMS tools such as xset dpms do not work in Wayland sessions.
The distinction between blanking a display and actually powering it off is compositor-specific and not standardized.
Many Wayland compositors rely on idle daemons or compositor-specific commands rather than a unified DPMS mechanism.

For example, wlroots-based compositors often use tools like swayidle to trigger output power changes. Hyprland exposes commands such as hyprctl dispatch dpms off, but there have been well-documented bugs where outputs fail to wake reliably or only partially recover. Some of these were closed upstream as not planned.

Given that context, it’s plausible this is an initialization or synchronization problem in the COSMIC Wayland greeter path, specifically involving cosmic-greeter, greetd, and their handling of display power events.

Why this matters

Waking the system is not an edge case. It’s a core interaction users hit dozens of times a day. Delays or blank screens here make the system feel broken, even if everything technically recovers eventually.

This also does not appear to be an isolated issue. There are already reports of:

Greeter startup delays
Blank greeter after wake
Greeter crashes tied to display events

Taken together, this strongly suggests that this part of the stack is still settling.

Logs around the wake event such as:

journalctl --since="-30s" --until="+30s" -u cosmic-greeter -u greetd

should help determine whether the delay is due to greeter startup time, a Wayland handshake stall, DPMS-related blocking, or something else entirely.

My setup

OS: Pop!_OS 24.04 LTS
Kernel: Linux 6.17.9-76061709-generic
GPU: NVIDIA GeForce RTX 3080 Ti
Driver: NVIDIA 580.95.05
cosmic-comp: 1.0.0
Graphics mode: nvidia

NVIDIA services nvidia-suspend, nvidia-resume, and nvidia-hibernate are enabled. PreserveVideoMemoryAllocations is set to 1, and I rebuilt initramfs using update-initramfs -c -k all before rebooting.

Notably, I do not see this behavior on my Intel ARC systems, only on NVIDIA systems, which may be a relevant data point.

Bigger picture

This fits a broader pattern. The COSMIC Wayland greeter stack is still maturing. That’s understandable for a new, Rust-based, Wayland-first implementation, and there’s a lot of impressive work here. However, it does matter when this ships as part of a 24.04 LTS.

An LTS release sets expectations. Regressions in basic workflows like waking the screen and logging in are not acceptable long-term, even if the underlying architecture is new and ambitious. New code is fine. Regressions are not.

I’m happy to help debug this further and can provide whatever logs are needed. I’ve been a kernel developer for over a decade and have significant experience with NVIDIA systems. I will likely reinstall Pop!_OS COSMIC shortly to gather clean logs and will follow up once I’ve had time to do that.

Per @leviport suggestion, I’m bringing this over to the discussion section. Thanks for making it known I should point this in discussions and not on issues alone. Sorry about that.

[winlinuxmatt]

I know many have acknowledged that display power management is still in progress. I tried to look for a similar discussion on this matter and was unable to find that.

GitHub feature request Monitor standby on lock isn’t implemented yet.
GitHub Github

Crash bug Compositor has issues when the display turns off.
GitHub

Community discussion Users explicitly asking if / when power management settings will be exposed.
Reddit

[winlinuxmatt]

I did see this is planned pop-os/cosmic-comp#517 and #172