DPMS wake leaves scratchpads pinned and surfaces unbound

[Sinity]

Hyprland: Scratchpads remain dim/unbound after DPMS wake + VT switch, leading to crash-prone state

Environment

• Host: sinnix-prime
• Hyprland 0.51.0 (3bcfa94e, 2025-10-02 build), aquamarine 0.9.4
• GPU: NVIDIA GA102 (RTX 3080) using GBM (GBM_BACKEND=nvidia-drm), monitor DP-3 AORUS FO48U at 3840x2160@60Hz
• Session managed by uwsm, Pyprland scratchpads configured for terminal and notes (pinned, sent to special: workspaces)
• Hypridle issues hyprctl dispatch dpms off after idle timeout

Reproduction outline

1. Let the system idle until hypridle runs hyprctl dispatch dpms off (monitor DP-3 powers down).
2. Wake the display after several hours; the compositor tears down DP-3 and recreates it (see log excerpt).
3. Observe pinned scratchpad clients rendered dimly over the desktop; attempting to dismiss them has previously crashed Hyprland.

Observed behaviour

• Upon DPMS wake the compositor fails GBM allocations for DRM_FORMAT_XRGB2101010, falls back to XBGR2101010 (hypr_bug_excerpt_20251005.log:1923950 onwards).
• Pyprland attempts to repin scratchpads while the seat is still deactivated, resulting in the windows staying mapped with monitor:-1 and special workspaces stuck active (hypr_bug_excerpt_20251005.log:1923688).
• While the session is inactive Hyprland repeatedly logs Attempted to render frame on inactive session! and Cannot enter surface … client hasn't bound the output for every application surface (hypr_bug_excerpt_20251005.log:1923867).
• Switching VTs hits BUG THIS: key not found in m_dPressedKeys (hypr_bug_excerpt_20251005.log:1924195) before Session got deactivated!.

Artifacts

• Log excerpt (701 lines)
• hyprctl clients dump before recovery
• Kitty window summary (redacted titles)
• hyprctl clients dump after recovery

Notes

• Scratchpads are managed by Pyprland (pyprland.toml); automation relies on workspace special: moves and pinning.
• User session runs on Hyprland 0.51.0 built via nix flakes (see /realm/sinnix/flake.lock).
• Happy to capture verbose logs or build a trace-enabled Hyprland if needed.

[vaxerski]

Scratchpads are managed by Pyprland

wouldn't that be a pyprland issue? In general, unless there is a specific issue pinpointed, I can't do much. You mentioned a crash, but didn't provide a crash report?

[Sinity]

I didn’t include a crash report initially because I was in a rescue TTY and had Codex moving windows around to keep the session alive, so there was no crash at the time I reported this. I’ve now reproduced the crash on the current 0.51.0 build (commit cfac272)* and gathered the artifacts:

• Crash report: https://gist.github.com/Sinity/3a1b34c9318ccfe4a3ed754daf3718df
• Log excerpt showing the failure (pypr toggle term → moveWorkspaceToMonitor workspace doesn't exist!): https://gist.github.com/Sinity/5f48b5b9e03a0c0210d9a0c450328ba4
• A coredump: hyprland-coredump-20251007.zst.gz - shows the compositor aborting in CCompositor::changeWindowZOrder, reached via Hyprctl’s alterZOrder.

Repro path:

1. Let hypridle turn the monitor off (dpms off).
2. Wake it.
3. Press my scratchpad toggle (pypr toggle term, Mod+N once) — the window flickers and stays up, dimming the background.
4. Press the same toggle again. Immediately after that, Hyprland logs “workspace doesn’t exist” and aborts.

About it being pypr issue, IDK, codex claims "Pyprland merely issues the Hyprctl commands—the compositor itself is asserting inside changeWindowZOrder".

* well technically there's also a patch overlay: https://gist.github.com/Sinity/49f722d9daaf8d751dd9d9840d95c1ee (it only adds a boolean guard so the HDR “imageDescription missing” warning logs once instead of flooding syslog with "~2.3e5 identical colour-management warnings"; issue unrelated to scratchpads). More info about that

[vaxerski]

patch.txt
try this for the crash?

[Sinity]

patch.txt try this for the crash?

I did apply it, I'll report if I'm still able to repro it.

[vaxerski]

also report if you arent able, then I'll commit it xd

[Sinity]

Well so far it didn't happen, so probably it works. I've thought to add logging, I've also asked codex to find what's the root cause and to look for similar issues. It did. System builds with these patches for me. Codex explains them like so:

Hyprland occasionally dereferences g_pCompositor->m_lastMonitor.lock() while that weak pointer is stale. A hot unplug or rapid focus change can make it expire before some listeners run, which causes the compositor to skip work silently or even crash depending on the call site.

1. setActiveMonitor updates m_lastMonitor only after it fires the focusedMon hook. Hook listeners that ignore the payload and instead grab m_lastMonitor see the old value (or nullptr). We’re shipping a patch that assigns m_lastMonitor = pMonitor->m_self before firing the hook; the hook payload is unchanged, but now the global matches it.
2. Even with the reorder, a couple of call sites still blindlydereferenced the weak pointer:
   • Renderer.cpp’s “render unfocused” timer attaches presentation feedback to m_lastMonitor.lock().
   • InputManager.cpp schedules cursor frames the same way when software cursors are in use.
     Both now check the lock result. If the monitor has disappeared, they emit a Debug::log(WARN, "[sinnix] …") and skip the work instead of using a null pointer.
3. I kept the existing damageMonitor guard and expanded its logging to include a 16-frame backtrace when it triggers. That can highlight any remaining edge cases if the guard ever fires again.

I audited other m_lastMonitor.lock() uses (window mapping, layer surfaces, debug overlay, pointer state). They already verify the lock or fall back to another monitor, so there aren’t more obvious crash paths of this type.

Taken together, the patches:

• Update m_lastMonitor before we broadcast focusedMon.
• Guard the remaining unprotected dereferences and warn when they would have run with a null monitor.
• Preserve the backtrace logging so regressions are visible in the Hyprland log (~/.local/share/hyprland/hyprland.log).

These fixes are ready to upstream; they don’t change behaviour for valid monitors and only affect the error paths.

If you only care about the monitor/null-pointer hardening, the essential patches are:

• focused-mon-before-hook.patch – fixes the root cause by updating m_lastMonitor before the focusedMon hook is emitted.
• guard-last-monitor.patch – adds the missing null checks in InputManager and the unfocused presentation path so we don’t crash (and we log when it happens).

The other Hyprland patches you’re carrying are independent quality-of-life tweaks:

• check-monitor-null.patch – keeps the safety guard and backtrace logging around damageMonitor so you can see if something regresses.
• hyprerror-focused-monitor.patch – teaches HyprError to use the hook payload directly; not strictly required after the reorder, but it avoids relying on global state.

So, to get upstream behaviour aligned, you really need the first two. The others are optional diagnostics/UI improvements you can include or drop according to taste.

focused-mon-before-hook.patch
guard-last-monitor.patch

check-monitor-null.patch
hyprerror-focused-monitor.patch