crashes after upgrade to 0.57.0 when DPMS is switched off

[balpert89]

Hyprland version

v0.57.1

Is this a regression?

Yes, never happened with v0.56.2

What's the bug?

I have hyprland & hypridle configured.

When the idle timer to switch off the monitor fires, it sometimes happens that its switching to the crash lock screen ("Ooopsie" in 0.57.0, this screen changed with 0.57.1).

Reproduction steps

I cannot reproduce it, happens randomly when I get back to my computer.

This is the version currently running:
hypridle:

hypridle v0.1.8

hyprland:

hyprland -v

Hyprland 0.57.1 built from branch v0.57.1 at commit acc1aa0bfd4bd575dcb0f76c35ccf12b660a1ab9 clean ([gha] Nix: update inputs).
Date: Tue Nov 3 09:45:48 2026
Tag: v0.57.1, commits: 7993

Libraries:
Hyprgraphics: built against 0.6.0, system has 0.6.0
Hyprutils: built against 0.14.3, system has 0.14.3
Hyprcursor: built against 0.1.13, system has 0.1.13
Hyprlang: built against 0.6.8, system has 0.6.8
Aquamarine: built against 0.16.0, system has 0.16.0

Version ABI string: acc1aa0bfd4bd575dcb0f76c35ccf12b660a1ab9_aq_0.16_hu_0.14_hg_0.6_hc_0.1_hlg_0.6
no flags were set

latest arch linux:

uname -r

7.2.14-arch1-1

Multi Monitor setup (unchanged before and after upgrade).
NVIDIA RTX 3090 with latest nvidia drivers installed.
AMD 9950X CPU.

This is different to the discussions revolving around Intel graphics so I started a new thread.

Attachments

I don't know which logs are helpful, nor where I can get them.

I acknowledge that:

• I have searched all (open and closed) discussions and issues and my problem is not there.

• I have read the Code of Conduct and agree to follow it.

• I wrote this request with my own hands, my own keyboard, and in my own words.

[vaxerski]

"oopsie" screen is not a crash. What lock are you using?

[balpert89]

Oh I thought this was changed because I have deactivated the idle timer for locking, and still experienced the safe-mode.

I am using hyprlock for locking.

hyprlock -V

Hyprlock version v0.9.7

Since this is happening even without the hyprlock-related timer, do you think this is related to the locking daemon?

This is the hyprlock configuration I am using:

background {
    monitor = DP-2
    path = /tmp/wallpaper1.png

    blur_size = 8
    blur_passes = 2
    noise = 0.0117
    contrast = 1.3000
    brightness = 0.8000
    vibrancy = 0.2100
    vibrancy_darkness = 0.0
}

background {
    monitor = HDMI-A-2
    path = /tmp/wallpaper2.png

    blur_size = 8
    blur_passes = 2
    noise = 0.0117
    contrast = 1.3000
    brightness = 0.8000
    vibrancy = 0.2100
    vibrancy_darkness = 0.0
}

background {
    monitor = HDMI-A-1
    path = /tmp/wallpaper3.png

    blur_size = 8
    blur_passes = 2
    noise = 0.0117
    contrast = 1.3000
    brightness = 0.8000
    vibrancy = 0.2100
    vibrancy_darkness = 0.0
}

input-field {
    monitor = HDMI-A-2
    size = 200, 50
    outline_thickness = 3
    dots_size = 0.33 # Scale of input-field height, 0.2 - 0.8
    dots_spacing = 0.15 # Scale of dots' absolute size, 0.0 - 1.0
    dots_center = true
    dots_rounding = -1
    outer_color = rgb(3b4261)
    inner_color = rgb(1a1b26)
    font_color = rgb(7aa2f7)
    fade_on_empty = false
    fade_timeout = 1000
    placeholder_text = <i>Password...</i>
    hide_input = false
    rounding = 5 # -1 means complete rounding (circle/oval)
    check_color = rgb(ff9e64)
    fail_color = rgb(ff9e64)
    fail_text = <i>$FAIL <b>($ATTEMPTS)</b></i>
    animation = inputFieldColors, 1, 3, default
    capslock_color = -1
    numlock_color = -1
    bothlock_color = -1
    invert_numlock = false
    swap_font_color = false
    position = 0, -20
    halign = center
    valign = center
}

label {
    monitor =
    #clock
    text = cmd[update:1000] echo "$TIME"
    color = rgba(200, 200, 200, 1.0)
    font_size = 55
    font_family = JetBrains Mono Semibold
    position = -90, 150
    halign = right
    valign = bottom
    shadow_passes = 5
    shadow_size = 10
}

label {
    monitor =
    #clock
    text = cmd[update:60000] echo "$(date +'%A, %-d %B %Y')"
    color = rgba(200, 200, 200, 1.0)
    font_size = 55
    font_family = JetBrains Mono Semibold
    position = -90, 50
    halign = right
    valign = bottom
    shadow_passes = 5
    shadow_size = 10
}

label {
    monitor = HDMI-A-2
    text = $USER
    color = rgb(7aa2f7)
    font_size = 25
    font_family = JetBrains Mono Semibold
    position = 0, 45
    halign = center
    valign = center
    shadow_passes = 5
    shadow_size = 10
}

and this is the hypridle configuration:

general {
    lock_cmd = pidof hyprlock || hyprlock
    before_sleep_cmd = loginctl lock-session
    after_sleep_cmd = hyprctl dispatch 'hl.dsp.dpms({action = "on"})' 
}

# Screenlock
# deactivated because of crashing
# listener {
#     timeout = 600
#     on-timeout = ~/.config/hypr/scripts/hyprlock.sh
# }

# dpms
listener {
    timeout = 600
    on-timeout = hyprctl dispatch 'hl.dsp.dpms({action = "off"})'
    on-resume = hyprctl dispatch 'hl.dsp.dpms({action = "on"})'
}

The script for locking:

#!/bin/bash

grim -o DP-2 -l 0 /tmp/wallpaper1.png & # run this command in background
grim -o HDMI-A-2 -l 0 /tmp/wallpaper2.png &
grim -o HDMI-A-1 -l 0 /tmp/wallpaper3.png &
# wait &&
hyprlock

[yerlotic]

@balpert89, try disabling before_sleep_cmd = loginctl lock-session, there might be a race condition where two instances of hyprlock try to lock the same session.

I could reproduce this bug with putting the device to sleep (systemctl suspend). In my case the issue was in my script, but your configuration works perfectly (with screenlock commented out).

One thing I noticed when testing your config, is that without before_sleep_cmd = loginctl lock-session it is around two times faster to suspend the pc (but the screen is still locked after resume)

[balpert89]

I am trying it out, though as mentioned I am also experiencing --safe-mode screens even when locking timer is disabled. suspension is never used in any case on my end.

[kbuckleys]

I've been having a similar issue when my monitors go idle, and it began with 0.57.1. Hyprland dies silently on dpms disable (NVIDIA, two monitors), then restarts in safe mode, locked. When an idle timer turns the outputs off, Hyprland exits immediately. The session is locked at the time by a Quickshell WlSessionLock. The command ishyprctl dispatch 'hl.dsp.dpms({ action = "disable" })'

There’s no crash report in ~/.cache/hyprland, no core dump, no “fatal signal” message, and nothing on stderr. The watchdog then logs Hyprland exit not-cleanly, restarting, and Hyprland comes back in safe mode with --locked, showing the lockdead screen. I can reproduce it every time. It started after aquamarine 0.16.0 / Hyprland 0.57.1.

My current workaround is to not power the outputs off with DPMS.

[balpert89]

This describes my situation almost exactly, just that I am using 3 monitors.

[mNandhu]

Same thing here, but I'm able to reproduce it every time. For me it only happens when the output on the NVIDIA GPU gets turned off (my external monitor).

My setup is a laptop: AMD iGPU & a GTX 1650m (card0, nvidia-open-dkms 615.78.08). Hyprland 0.57.1, aquamarine 0.16.0, hyprutils 0.14.3, mesa 26.2.6, kernel 7.2.14-arch1-1 on Arch. I don't set AQ_DRM_DEVICES, so aquamarine renders on the AMD iGPU and sets up the NVIDIA card as the secondary renderer (Initializing secondary renderer on /dev/dri/card0, GBM: Buffer is marked as multigpu, forcing linear). eDP-1 (1920x1080@60) is on the iGPU. HDMI-A-1 (1920x1080@180) is on the NVIDIA card and is the only output for it. Hyprland is started from greetd through start-hyprland. I don't use hypridle. My shell (Caelestia/quickshell) sends the DPMS dispatch, but plain hyprctl does about the same thing.

With the session unlocked and nothing special open - turning off monitors:

hyprctl dispatch 'hl.dsp.dpms({ action = "disable", monitor = "eDP-1" })'     # fine
hyprctl dispatch 'hl.dsp.dpms({ action = "enable",  monitor = "eDP-1" })'     # fine, same PID
hyprctl dispatch 'hl.dsp.dpms({ action = "disable", monitor = "HDMI-A-1" })'  # Hyprland dies within ~1 s
hyprctl dispatch 'hl.dsp.dpms({ action = "disable" })'                        # all outputs: also dies within ~1 s

I ran these from a script started with systemd-run --user so the results would survive the crash. After the HDMI disable the socket goes away and start-hyprland brings up safe mode (one time it went straight back to the greeter instead). The first time I hit this, it was the idle timeout firing while the session was locked, so I got the "Oopsie daisy" screen. When it's unlocked I get the "Safe mode" screen, so I don't think the lock has anything to do with it.

It leaves nothing behind. no coredump, no hyprlandCrashReport, no segfault line from the kernel, and no NVRM or drm errors in the journal. hyprland.log doesn't even reach drm: Disabling output HDMI-A-1. The last lines are from re-enabling eDP-1 right before:

DEBUG from aquamarine ]: drm: backup slot 0 crtc 103 assigned to disabled eDP-1
DEBUG from aquamarine ]: drm: Modesetting eDP-1 with 1920x1080@60.01Hz
DEBUG from aquamarine ]: drm: Connector eDP-1 enabledState changed false -> true

My guess, since HDMI is the secondary GPU's only output, is that turning it off goes down the "Deinitializing secondary renderer …, no enabled outputs" path (the teardown in hyprwm/aquamarine#324 and hyprwm/aquamarine#474) and it dies somewhere in there. The way the log just stops also looks like what someone described in #16801, where the watchdog kills a stuck main thread, so this might be a hang and not a segfault.

Update: it's not a regression from today's update. I rolled back piece by piece and re-ran the HDMI disable each time. It still dies the same way on:

• Hyprland 0.57.0 / aquamarine 0.15.1 (with hyprgraphics 0.5.1, hyprtoolkit 0.6.0-1)
• kernel 6.18.60-lts instead of 7.2.14 (same nvidia 615.78.08)
• expat, lcms2, harfbuzz and glycin rolled back to their previous versions

So it's probably been there since I moved to nvidia 615 / Hyprland 0.57 last week, and today was just the first time HDMI got turned off on idle.

There's also a second way to hit it, which I think is the same bug from the other side: unplug HDMI while the session is running (aquamarine logs Deinitializing secondary renderer on /dev/dri/card0, no enabled outputs and the session is fine), suspend, plug the monitor back in while it's asleep, resume. The log ends at [libseat] Enabling seat, right before it would pick up HDMI again, and the session is gone. Again no coredump.

The one crash that does leave a core is the greeter. My greetd greeter runs its own Hyprland, and it segfaults on exit every time I log in, on every combination above. Oddly those only started today (no coredumps before, even with the same versions I rolled back to), so that part might be its own thing:

#0  libc.so.6 + 0x17911d
#1  libaquamarine.so.15 + 0x6d9ef
#2  libaquamarine.so.15 + 0x70fdd
#3  libaquamarine.so.15 + 0x729df
#4  libaquamarine.so.15 + 0xeab96
#5  libEGL.so.1 + 0x616c
#6  libEGL.so.1 + 0x7a3a
#7  eglDestroyContext (libEGL.so.1)
#8  Aquamarine::CDRMRenderer::~CDRMRenderer()
#9  CSharedPointer<Aquamarine::CDRMRenderer>::_delete
#10 libaquamarine.so.15 + 0x66689
#11 Aquamarine::CDRMBackend::~CDRMBackend()
...
#16 __cxa_finalize
#21 exit

That's the renderer destructor again, so it fits the secondary renderer teardown guess. Happy to get a full symbolized trace or perf data if someone tells me what's most useful.

For now I've changed my idle config to only turn off the iGPU panel (monitor = "eDP-1"), and I log out and back in after unplugging HDMI.