eDP panel wedges (backlight on, no scanout) after idle-driven DPMS off/on cycle — probabilistic per cycle, regression in 0.11.0

[spheenik]

Summary

After upgrading aquamarine 0.10.0 → 0.11.0, an idle-driven DPMS off/on cycle (e.g. hypridle running hyprctl dispatch "dpms off" on idle and dpms on on resume) intermittently leaves the eDP panel with backlight powered on but no scanout. Hyprland reports dpmsStatus: 1, the dispatch returns ok, but aquamarine emits no further commits. Once wedged, only restarting Hyprland recovers — hyprctl reload, additional DPMS cycles, and explicit hl.monitor({disabled=true}) then disabled=false all return ok but produce zero new aquamarine output and do not recover the panel.

The bug is probabilistic — about 15–20% per cycle. Manual back-to-back hyprctl dispatch dpms off/on cycles (without going through the wayland idle protocol path) do not reproduce it.

Possibly related to #293 (same backlight-on/no-scanout symptom, same aquamarine 0.11.0 regression, same restart-only recovery), but the trigger is different (idle-driven DPMS, not explicit monitor disable/re-enable).

System

• aquamarine: 0.11.0-2 (broken). 0.10.0-4 was fine (cannot use the package directly with Hyprland 0.55 due to soname bump 9 → 10)
• Hyprland: 0.55.0-4
• Kernel: 7.0.5.arch1-1
• Distro: Arch Linux
• GPU: AMD Radeon 780M iGPU (amdgpu)
• Panel: eDP-1, Thermotrex TL140ADXP22-0, 2880x1800@60Hz, scale 2.0
• Idle daemon: hypridle (latest)
• Reproduced on a second machine: AMD Ryzen 9 9950X desktop (different amdgpu, no VRR, no eDP) — same wedge symptom following the same idle-driven DPMS pattern

Note on kernel upgrade: the kernel was upgraded in the same window as aquamarine (linux 6.19.10 → 7.0.5 on the laptop, 6.19.12 → 7.0.5 on the desktop). I have not isolated kernel from aquamarine as the regression source — both changed at the same time, and downgrading aquamarine alone is blocked by the soname bump (0.10.0 provides libaquamarine.so=9, Hyprland 0.55 requires =10). The match with #293's symptom signature (which was reproduced on multiple kernels including 7.0.3 and 6.18.26 LTS) makes aquamarine the prime suspect, but I cannot rule out the kernel.

Steps to reproduce

1. Single eDP output (no external monitors, no VRR — VRR is not required).
2. Run hypridle with this listener (any short timeout works; 5s for fast iteration):

   listener {
       timeout = 5
       on-timeout = hyprctl dispatch "dpms off"
       on-resume  = hyprctl dispatch "dpms on"
   }
   

3. Stop touching input devices for timeout seconds → hypridle fires dpms off, panel goes off (correctly).
4. Wiggle mouse → hypridle fires dpms on. Most cycles work normally; ~1 in 5 leaves the panel wedged: backlight on, no image, hyprctl monitors reports dpmsStatus: 1, dispatch returned ok.
5. Once wedged, no further activity in hyprland.log from aquamarine. Only hyprctl dispatch exit (Hyprland restart) recovers.

In four runs (timeouts 15s, 15s, 5s, 60s), the wedge appeared at cycles 5, 5, 9, 3 respectively — average ~5.5, consistent with ~15–20% per-cycle probability. The off-time per cycle and Hyprland uptime do not predict the wedge — only the cumulative number of Idled → dpms off → Resumed → dpms on event pairs does.

Aquamarine log at the wedge

The last lines from hyprland.log immediately before the panel wedges:

DEBUG from aquamarine ]: drm: Disabling output eDP-1
DEBUG from aquamarine ]: drm: Modesetting eDP-1 with 2880x1800@60.00Hz

After this, no further aquamarine entries are written even though subsequent dispatches (including hl.monitor({disabled=true/false}) re-enable, hyprctl reload, additional DPMS cycles, mouse input) all return ok from the IPC. Frame submission to the CRTC stops entirely.

Hypridle cycle log (60s test, wedge on cycle 3)

[01:24:53] idle: dpms off
[01:25:34] cycle 1: dispatching dpms on   (off duration 41s — worked)
[01:26:34] idle: dpms off
[01:27:14] cycle 2: dispatching dpms on   (off duration 39s — worked)
[01:28:15] idle: dpms off
[01:28:40] cycle 3: dispatching dpms on   (off duration 25s — wedged)

What does not recover the wedged state

All return ok from the IPC, all produce zero new aquamarine log lines, none restore scanout:

• Another dpms off → dpms on cycle
• hyprctl reload
• hl.monitor({output="eDP-1", disabled=true}) then disabled=false, mode="preferred", position="auto", scale=2
• VT switch + return

Only hyprctl dispatch exit (full Hyprland restart) recovers.

What does NOT trigger the wedge

• Manual back-to-back hyprctl dispatch "dpms off" / dpms on calls with 5s gaps — multiple cycles, no wedge in any test
• A single isolated hypridle-driven cycle (very low probability — happens occasionally per the per-cycle probability)

The wayland idle protocol path (Idled event in compositor before dpms-off) appears necessary for the bug to manifest, suggesting interaction between the compositor's idle state and aquamarine's output re-enable bookkeeping.

Possible relation to #293

Same aquamarine 0.11.0 regression, same backlight-on/no-scanout symptom, same restart-only recovery, same Modesetting … with WIDTHxHEIGHT@RATE log signature with no commits afterwards. Different trigger (idle-DPMS vs explicit monitor disable/re-enable). May or may not share root cause — happy to test patches against either path.

[spheenik]

Root cause analysis

I dug into the diff between v0.10.0 and v0.11.0 and traced what I think is the root cause. Posting the analysis in case it's useful — I have not built or tested the proposed fixes yet.

The breaking change

PR #241 ("drm: make pageflips drive the frames", commit 603f5cd) replaces the idle-dispatch frame scheduler with one driven by kernel page-flip completion events. Motivation per the PR description: latency reduction (the old idle-dispatch added a wakeup gap before each frame).

After this change, frames are only re-scheduled when handlePF() runs, and handlePF() is the only place that clears isPageFlipPending (DRM.cpp:1113):

static void handlePF(...) {
    ...
    pageFlip->connector->isPageFlipPending = false;
    ...
}

scheduleFrame() (DRM.cpp:2294) early-returns whenever isPageFlipPending is true:

if (connector->isPageFlipPending || connector->isFrameRunning || connector->frameEventScheduled || !enabledState)
    return;

The new design implicitly assumes every submitted commit produces exactly one page-flip completion event. That holds for the steady-state render loop, but not across enable/disable transitions: atomic disable commits don't produce flip events (nothing to flip to), and frames submitted just before the panel powers down are dropped by the kernel because the CRTC is gone. The old idle-dispatch scheduler was self-healing because it kept ticking regardless; the new model needs explicit recovery at every "no event coming" boundary.

Why DPMS off/on wedges

When dpms('off') runs, an atomic commit disables the connector. Any page-flip submitted just before is "stranded": the kernel powers down the output and the completion event never arrives at handlePF(). isPageFlipPending stays true indefinitely.

When dpms('on') later runs, aquamarine submits a re-enable modeset. The log shows it succeeds:

DEBUG from aquamarine ]: drm: Modesetting eDP-1 with 2880x1800@60.00Hz

…and then nothing further, because:

• scheduleFrame() early-returns on the stale isPageFlipPending = true
• The compositor is never told a frame is ready
• No new commit is submitted
• No further handlePF() invocation, so isPageFlipPending is never cleared

Result: backlight on, dpmsStatus: 1, no scanout, no further log activity. Only Hyprland exit + restart recovers (because the connector and its flag are reconstructed from scratch).

Why pre-0.11 wasn't affected

The old idle-dispatch scheduler would re-fire periodically regardless of page-flip event delivery, masking this case (a frame would just be a frame late). PR #241 made the latent bug uncoverable.

Existing partial mitigations

Two cleanups already exist for adjacent boundaries (both from commit f5cdaa8, "drm: CRTC starvation recovery + clear stale page-flip state after suspend", PR #254 — not in any released tag):

1. restoreAfterVT() (DRM.cpp:393) clears the stale flags after S3 suspend / VT switch — handles those boundaries.
2. A 500ms commit-time watchdog (DRM.cpp:1985):

   bool staleFlip = (nowMs - connector->pageFlipPendingAtMs) > 500;
   if (NEEDS_RECONFIG && staleFlip) { /* clear stale flags */ }

   This kicks in only when a new commit attempt arrives. It can't help when no commit is ever attempted — which is exactly the DPMS-on case, since applyCommit doesn't scheduleFrame() on the false→true transition (DRM.cpp:1815-1826), and nobody else does either. With stale flags blocking scheduleFrame(), no commit is ever submitted, and the watchdog never gets to fire.

So both holes need closing for the wedge to be impossible: clear stale flags at the disable boundary (so scheduleFrame() works), AND make sure something kicks the frame chain after re-enable.

The same root cause (stale isPageFlipPending) explains #293's wedge from the explicit-monitor-disable path.

---

Proposed fixes — three layers, pick whichever fits

(1) Surgical patch — covers the immediate symptom

Mirror the restoreAfterVT() cleanup at the disable boundary in applyCommit:

--- a/src/backend/drm/DRM.cpp
+++ b/src/backend/drm/DRM.cpp
@@ -1806,8 +1806,16 @@ void Aquamarine::SDRMConnector::applyCommit(const SDRMConnectorCommitData& data)
     const bool wasEnabled = output->enabledState;
     output->enabledState  = output->state->state().enabled;
 
-    if (!output->enabledState)
+    if (!output->enabledState) {
         releaseFBReferences();
+        // Disabling the connector (DPMS-off, monitor disable, etc.).
+        // Any in-flight page-flip will never complete because the kernel
+        // powers down the output, so its completion event won't reach
+        // handlePF() to clear isPageFlipPending. Leaving these flags stale
+        // would cause scheduleFrame() to return early forever on re-enable,
+        // leaving the output black-with-backlight-on. Same pattern as the
+        // suspend/VT cleanup in restoreAfterVT().
+        isPageFlipPending   = false;
+        isFrameRunning      = false;
+        frameEventScheduled = false;
+    }
 
     if (!backend->updateSecondaryRendererState())

This might fix this issue and #293 (same root cause, same stranded flag). 8 lines, mirrors an existing pattern. Untested.

(2) Self-firing watchdog — covers all current and future "lost event" boundaries

The 500ms threshold and timestamp infrastructure already exist (pageFlipPendingAtMs). Promote them from a "checked-on-next-commit" check to an actual timerfd_create() armed when a flip is submitted and disarmed on handlePF(). On expiry: clear stale flags AND events.frame.emit() (or scheduleFrame()) to bootstrap. No need to enumerate every "no event coming" boundary — covers DPMS-off, monitor disable, suspend, VT switch, DRM lease revoke, hotplug-mid-flip, kernel bugs, mGPU oddities, anything present or future. The piecemeal approach (restoreAfterVT, the disable patch above, presumably more later) becomes unnecessary because the system is self-healing regardless of why the event went missing.

(3) Encapsulate as CFlipTracker — fixes the type-safety gap that lets these bugs slip in

The state is currently smeared across 3-4 raw bools on the connector with setters and readers in 7+ files (Atomic.cpp, Legacy.cpp, handlePF(), applyCommit(), restoreAfterVT(), the commit-time watchdog, the destructor, scheduleFrame()). Every site has to remember to twiddle the right combination of fields, and "I'm clearing this for a normal completion" looks identical to "I'm clearing this because the event won't come". A small owning class with intent-named methods would collapse all of this:

class CFlipTracker {
public:
    void markSubmitted();          // commit with PAGE_FLIP_EVENT was accepted
    void markCompleted();          // handlePF arrived
    void markCancelled();          // kernel won't deliver event (disable, suspend, VT, hotplug)
    bool isPending() const;
    bool isStale() const;          // internal 500ms threshold
    
    sigslot::signal<> flipLost;    // emitted when watchdog timer fires
    
private:
    bool     pending = false;
    bool     frameRunning = false;
    bool     frameEventScheduled = false;
    uint64_t submittedAtMs = 0;
    int      watchdogFd = -1;      // timerfd, armed on submit, disarmed on complete
};

Where	Today	With CFlipTracker
Atomic.cpp:506	isPageFlipPending = true; ts = ...	flips.markSubmitted()
handlePF	isPageFlipPending = false	flips.markCompleted()
applyCommit on disable	(missing — the bug)	flips.markCancelled()
restoreAfterVT loop	5 lines per connector	flips.markCancelled()
scheduleFrame guard	4-bool conjunction	if (flips.isPending())
Commit-time watchdog	20-line ad-hoc check	flips.isStale()
CDRMOutput dtor	2 lines	flips.markCancelled()

The flipLost signal wires once at connector init: when it fires, clear-and-bootstrap. That single subscription absorbs the "I have to remember to also kick the frame chain" concern. Both layer (1)'s boundary cleanup and layer (2)'s self-firing watchdog fall out for free, in one place. ~150 lines of changes total, mostly mechanical, with the actual bug-fix being one new markCancelled() call.

Type-safety payoff: today, isPageFlipPending = false looks identical whether it's a normal completion, a cancelled flip, or an accidental double-clear (which probably should also clear isFrameRunning and frameEventScheduled — easy to forget). Named intent methods make those three cases visibly different at every call site.

---

Happy to build and test layer (1) locally before any potential PR if that would help. Layers (2) and (3) feel like the maintainers' call. cc #293

[spheenik]

Correction — diagnosis is incomplete

I owe a correction on the analysis above. After posting, I ran a control test that contradicts the "stale isPageFlipPending from in-flight frame at disable" mechanism as a complete explanation:

Test: 20 back-to-back manual cycles via hyprctl dispatch "hl.dsp.dpms('off')" / dpms('on'), 2 s gap each direction, on a separate machine (AMD desktop, no eDP, no VRR, dual-monitor — both outputs toggled together; the per-monitor second arg to hl.dsp.dpms did not appear to be honored on this version).

Result: 20 / 20 cycles clean. No wedge.

That should have hit something if the trigger were per-cycle (~15–20 % rate observed via hypridle gives <2 % chance of 20 manual cycles all surviving). So the wayland-idle path is necessary, not just a coincidental observation. My proposed mechanism would have triggered in the manual loop too — it doesn't.

What this means:

• The patch is still defensible as a hardening — clearing the stale flags at the disable boundary is harmless when nothing was stranded, and matches the existing pattern in restoreAfterVT(). It's a good change on its own merits even if it doesn't turn out to be the actual fix for this issue.
• The actual trigger is something idle-path-specific that I haven't identified. Candidates:
  • During wayland idle, Hyprland may stop issuing commits — so by the time dpms('off') arrives there's no recent flip in flight, no stale flag set by my mechanism, and the wedge cause is elsewhere.
  • The last commit submitted before idle has its flip arrive during the idle period (when Hyprland may be in a different scheduling state) and hits a mishandled path.
  • Some interaction with the wayland-idle → Resumed → dpms('on') ordering specifically (a Resumed event always precedes the dpms('on') dispatch in the idle path, never in the manual path).
• The "Modesetting … @ RATE then silence" log signature is still real, and scheduleFrame() still early-returning is still consistent with something keeping it from running, just maybe not the flag I named.

So: take the surgical patch as a defensive cleanup if useful, but please don't trust my "root cause" framing without verification — the manual control disproved the strong form. Maintainers with insight into the wayland-idle handling path are likely better placed to find the actual mechanism. Happy to run further targeted tests on either machine if there are specific hypotheses to probe.

[spheenik]

Update — original hypothesis vindicated by a new control test

Walking back the previous correction. The original "stale isPageFlipPending from in-flight frame at disable" mechanism is the root cause. The earlier 20-cycle manual loop didn't reproduce because the manual cycles were dispatched into a quiescent compositor with no recent frame submissions — by the time dpms('off') arrived, any prior flip had long since been acknowledged.

Adding a single deliberate frame submission immediately before each dpms('off') changes that. New test:

for i in $(seq 1 20); do
    ydotool mousemove -- 5 0           # ← forces a frame on the active output
    hyprctl dispatch "hl.dsp.dpms('off')"
    sleep 2
    hyprctl dispatch "hl.dsp.dpms('on')"
    sleep 2
done

Tested on the same AMD desktop (dual-monitor, Hyprland 0.55.0, aquamarine 0.11.0-2, kernel 7.0.5).

Result: Compositor wedged before the loop finished. All 20 cycles' hyprctl dispatch calls returned ok and the loop completed cleanly per its own log, but Hyprland itself ended up unable to make forward render progress. hyprctl monitors IPC remained responsive (dpmsStatus: True on both outputs), the screens still displayed the last good frame, but input/animation/cursor froze and only hl.dsp.exit() recovered.

The aquamarine log shows the smoking gun. During the loop, the same error from hyprwm/Hyprland#14521 appeared nine times:

ERR from aquamarine ]: drm: Cannot commit when a page-flip is awaiting
ERR from aquamarine ]: drm: Cannot commit when a page-flip is awaiting
ERR from aquamarine ]: drm: Cannot commit when a page-flip is awaiting
ERR from aquamarine ]: drm: Cannot commit when a page-flip is awaiting
ERR from aquamarine ]: drm: Cannot commit when a page-flip is awaiting
ERR from aquamarine ]: drm: Cannot commit when a page-flip is awaiting
ERR from aquamarine ]: drm: Cannot commit when a page-flip is awaiting
ERR from aquamarine ]: drm: Cannot commit when a page-flip is awaiting
ERR from aquamarine ]: drm: Cannot commit when a page-flip is awaiting

Same root cause as the wedge in this issue, just a different visible symptom because Hyprland is in a different render-loop state at the time of failure:

Path	What happens after stranded isPageFlipPending
Idle / hypridle (this issue, eDP)	scheduleFrame() early-returns; nothing tries to commit; no commits = no commit-time errors logged; no rendering = backlight on, no scanout
Manual loop with forced frame (zoidberg)	Hyprland keeps trying to commit (cursor follows input, animations); aquamarine rejects every commit with "Cannot commit when a page-flip is awaiting"; compositor frozen on last good frame

Both = isPageFlipPending left true after disable powered down the connector before its event arrived. The 500 ms watchdog at DRM.cpp:1985 doesn't save the manual case because the rejected commits are not modesets (NEEDS_RECONFIG is false), so the watchdog branch is skipped and the commit just gets rejected.

This also reproduces the exact failure mode of hyprwm/Hyprland#14521 (Cannot commit when a page-flip is awaiting after a disable→re-enable transition), which suggests both #304 and hyprwm/Hyprland#14521 share the stranded-flag root cause.

The trigger asymmetry I previously couldn't explain is now clear: the wayland-idle path always has a "final frame on entering idle" submission that races with dpms('off'). The manual cycle path normally doesn't — but if you inject a frame submission immediately before disable (cursor warp / hotplug-induced rescan / etc), it reproduces too.

So the original surgical patch (clearing the stale flags at the disable boundary in applyCommit()) really is targeting the mechanism, not just defensive cleanup. Posting again for clarity:

--- a/src/backend/drm/DRM.cpp
+++ b/src/backend/drm/DRM.cpp
@@ -1806,8 +1806,16 @@ void Aquamarine::SDRMConnector::applyCommit(const SDRMConnectorCommitData& data)
     const bool wasEnabled = output->enabledState;
     output->enabledState  = output->state->state().enabled;
 
-    if (!output->enabledState)
+    if (!output->enabledState) {
         releaseFBReferences();
+        // Disabling the connector (DPMS-off, monitor disable, etc.).
+        // Any in-flight page-flip will never complete because the kernel
+        // powers down the output, so its completion event won't reach
+        // handlePF() to clear isPageFlipPending. Same pattern as the
+        // suspend/VT cleanup in restoreAfterVT(). Without it,
+        // commitState() rejects every subsequent commit with "Cannot
+        // commit when a page-flip is awaiting" (issue #304 / hyprwm/Hyprland#14521 / #293).
+        isPageFlipPending   = false;
+        isFrameRunning      = false;
+        frameEventScheduled = false;
+    }
 
     if (!backend->updateSecondaryRendererState())

Side observation from the same test run: every dpms('off') triggered a fresh udev hotplug change event for /dev/dri/card1 and a full connector rescan. That's a lot of redundant churn for a userspace-driven DPMS toggle, and probably increases the window where a flip can get stranded; might be worth a separate look.

Logs preserved locally if any would be useful for upstream verification.

[gularsson]

Confirming this on a different trigger / hardware combination — boot-time, not user-driven, on Intel Lunar Lake with the xe driver. Posting because spheenik's open question was whether the proposed patch covers the actual mechanism; on my hardware it does.

Hardware / software

GPU	Intel Lunar Lake (display version 20.00 stepping B0), xe driver
Panel	eDP-1, Samsung 0x419F, 2880×1800@120
Kernel	6.18.28 (with xe.enable_psr=0 xe.enable_dc=0 cmdline)
Mesa	26.1.0
Hyprland	0.55.0+date=2026-05-15_b74b1f9 (latest)
aquamarine	0.11.0 + the disable-boundary patch from #304
Distro	NixOS unstable (hyprland pinned from the upstream flake)