Summary
After upgrading from aquamarine 0.10.x (Hyprland 0.54) to a post-v0.11.0 build that includes f5cdaa8 ("drm: CRTC starvation recovery + clear stale page-flip state after suspend (#254)"), the eDP panel still wedges on a lid-close → suspend → lid-open cycle. Same wedge symptom as #304 (backlight on, no scanout, only compositor restart recovers), but the f5cdaa8 recovery does not catch this case. The wedge is not memory-pressure related: a per-process RSS poller running every 10s shows Hyprland holding ~50 MB across the entire reproduction.
Filing because f5cdaa8 was the targeted fix for this family and it's clearly only partial on Intel i915 setups. Cross-reference #304 (same wedge symptom, AMD, idle-DPMS trigger; this report is i915 + lid-suspend trigger).
System
- GPU: Intel Raptor Lake-U [8086:a7ac], i915 driver. Single eDP-1 internal panel, no external outputs.
- Hyprland: 0.55.1 (nixpkgs build, commit
a47147bc), Lua config.
- Aquamarine: built from main at
ab2b0af6 (10 commits past v0.11.0). f5cdaa8 verified active in the loaded library — all eight of its new log strings (Clearing stale page-flip state for ..., backup slot {} crtc {} assigned to disabled {}, Connector {} enabledState changed, etc.) are present in the running libaquamarine.so.
- Kernel: 6.18.31 (NixOS unstable).
- Session manager: UWSM with atomic DRM (no
AQ_NO_ATOMIC).
- Other libs: Hyprutils 0.13.1, Hyprgraphics 0.5.1, Hyprcursor 0.1.13, Hyprlang 0.6.8.
Reproduction
Plain lid-close to lid-open cycle. Both short (~6 min) and long (~7 hour) suspends reproduce the wedge. The full lifecycle:
- Compositor running normally, Hyprland RSS ~50 MB.
- User closes lid → logind suspends (s2idle).
- After N minutes, user opens lid → kernel resumes.
- Lock screen (hyprlock, started on lid-close via Hyprland's
switch:on:Lid Switch binding) flashes once — clock + password entry briefly visible.
- Display goes black. Input is dead. Backlight stays on.
- Only recovery is hard power-off via the power button.
The brief visible frame at step 4 indicates Hyprland resumed enough to render at least once before stalling — distinct from a full compositor freeze.
Evidence this is not memory pressure
A per-process RSS poller (10s interval) ran across one of the wedge reproductions. Trajectory across the lid cycle:
2026-05-21T12:28:09 pid=3487 rss=49672 KB ← pre-suspend
2026-05-21T12:28:20 pid=3487 rss=49584 KB
2026-05-21T12:28:30 pid=3487 rss=49584 KB
2026-05-21T12:28:41 pid=3487 rss=49584 KB
lid closed 12:28:48, suspended ~6 min
2026-05-21T12:34:49 pid=3487 rss=50624 KB ← post-resume, +1 MB
2026-05-21T12:34:59 pid=3487 rss=51336 KB
user power-key at 12:35:04
Hyprland's wayland-wm@hyprland.desktop.service service had its peak RSS at well under 200 MB for the entire session.
Earlier session (different aquamarine, illustrative)
For context, a separate failure mode also exists on this machine when running without AQ_NO_ATOMIC and without f5cdaa8 — the compositor accumulates ~11 GB RSS over an hour and tips into OOM thrash on resume. f5cdaa8 plus avoiding the legacy path eliminates that mode entirely. The wedge being reported here is the other failure mode that survives f5cdaa8.
Log-capture limitation
Hyprland's runtime log lives at `$XDG_RUNTIME_DIR/hypr//hyprland.log` on tmpfs, wiped at hard power-off. A `tail -F` mirror to disk works for slow-burn cases but loses the last block-buffer (typically the last 4 KB of writes that never flushed). For this wedge the mirror file's mtime stops minutes before the lid-close event — Hyprland's stdio block buffer simply doesn't fill during the quiet lead-up + suspend + brief post-resume window before the hard power-off. So I do not have an internal Hyprland log of the actual wedge moment to attach here. Happy to investigate alternate capture approaches if helpful.
Related
Summary
After upgrading from aquamarine 0.10.x (Hyprland 0.54) to a post-v0.11.0 build that includes
f5cdaa8("drm: CRTC starvation recovery + clear stale page-flip state after suspend (#254)"), the eDP panel still wedges on a lid-close → suspend → lid-open cycle. Same wedge symptom as #304 (backlight on, no scanout, only compositor restart recovers), but the f5cdaa8 recovery does not catch this case. The wedge is not memory-pressure related: a per-process RSS poller running every 10s shows Hyprland holding ~50 MB across the entire reproduction.Filing because f5cdaa8 was the targeted fix for this family and it's clearly only partial on Intel i915 setups. Cross-reference #304 (same wedge symptom, AMD, idle-DPMS trigger; this report is i915 + lid-suspend trigger).
System
a47147bc), Lua config.ab2b0af6(10 commits past v0.11.0). f5cdaa8 verified active in the loaded library — all eight of its new log strings (Clearing stale page-flip state for ...,backup slot {} crtc {} assigned to disabled {},Connector {} enabledState changed, etc.) are present in the runninglibaquamarine.so.AQ_NO_ATOMIC).Reproduction
Plain lid-close to lid-open cycle. Both short (~6 min) and long (~7 hour) suspends reproduce the wedge. The full lifecycle:
switch:on:Lid Switchbinding) flashes once — clock + password entry briefly visible.The brief visible frame at step 4 indicates Hyprland resumed enough to render at least once before stalling — distinct from a full compositor freeze.
Evidence this is not memory pressure
A per-process RSS poller (10s interval) ran across one of the wedge reproductions. Trajectory across the lid cycle:
Hyprland's
wayland-wm@hyprland.desktop.serviceservice had its peak RSS at well under 200 MB for the entire session.Earlier session (different aquamarine, illustrative)
For context, a separate failure mode also exists on this machine when running without AQ_NO_ATOMIC and without f5cdaa8 — the compositor accumulates ~11 GB RSS over an hour and tips into OOM thrash on resume. f5cdaa8 plus avoiding the legacy path eliminates that mode entirely. The wedge being reported here is the other failure mode that survives f5cdaa8.
Log-capture limitation
Hyprland's runtime log lives at `$XDG_RUNTIME_DIR/hypr//hyprland.log` on tmpfs, wiped at hard power-off. A `tail -F` mirror to disk works for slow-burn cases but loses the last block-buffer (typically the last 4 KB of writes that never flushed). For this wedge the mirror file's mtime stops minutes before the lid-close event — Hyprland's stdio block buffer simply doesn't fill during the quiet lead-up + suspend + brief post-resume window before the hard power-off. So I do not have an internal Hyprland log of the actual wedge moment to attach here. Happy to investigate alternate capture approaches if helpful.
Related