DPMS enable does not retrain DP link: panel stays black while dpmsStatus reports 1 (5120x1440@144, Intel Arrow Lake-S)

[TripleU613]

DPMS enable does not retrain the DP link — panel stays black while dpmsStatus: 1

Summary

On an Intel Arrow Lake-S iGPU driving a Samsung Odyssey G91SD at its preferred mode
5120x1440@143.99, a DPMS off → on cycle leaves the panel permanently black. Hyprland reports
the output as fully healthy the whole time — dpmsStatus: 1, disabled: false, correct mode,
no config errors — but no frames reach the panel. Only a real mode change recovers it.
Re-applying the same mode is a no-op and does not help.

This left the machine with an unusable display for ~16 hours. It is recoverable only over SSH,
or presumably by a reboot.

Environment

Hyprland	0.56.2 (efb5099, tag v0.56.2)
aquamarine	0.15.0-2
Kernel	7.2.3-arch1-3 (Arch)
Mesa	1:26.2.2-1
GPU (driving display)	Intel Arrow Lake-S [8086:7d67] — card0
Second GPU (idle)	NVIDIA RTX A1000 [10de:25b0]
Monitor	Samsung Odyssey G91SD, DP-5, preferred 5120x1440@143.99 (needs DSC)
Shell	quickshell 0.3.1-1, omarchy-dev 4.0.0.r2071

Reproduction

1. Be at the preferred mode 5120x1440@143.99 on DP-5.
2. hyprctl dispatch 'hl.dsp.dpms({ action = "disable" })' — panel goes off, as expected.
   (In practice this is what Omarchy's lock does automatically 5s after locking.)
3. hyprctl dispatch 'hl.dsp.dpms({ action = "enable" })' — returns ok.
4. Panel stays black. hyprctl monitors reports dpmsStatus: 1, disabled: false, mode
   5120x1440@143.98700, currentFormat: XRGB8888. No config errors.

Physical input (keyboard, mouse) does not help — it is correctly delivered and does trigger
another dpms enable, which again reports success while the panel stays dark.

Evidence that no frames are produced

grim is a clean discriminator, since it waits on a frame:

# while wedged
$ timeout 15 grim -o DP-5 -s 0.15 /tmp/sc.png
# → times out, file is never created (0 bytes)

# after recovery
$ timeout 15 grim -o DP-5 -s 0.15 /tmp/sc.png; echo rc=$?
rc=0            # 111307-byte PNG

Hyprland's main thread sits in do_epoll_wait at 0.0% CPU while wedged — it is not spinning or
deadlocked, it simply never produces a frame. hyprland.log stops mid-word at the point of the
last connector rescan and is not appended to again.

Recovery — mode change is required

Re-applying the same mode does nothing (hyprctl reload at the preferred mode is a no-op —
no modeset occurs, panel stays black). Changing to any other mode lights the panel instantly:

-- ~/.config/hypr/monitors.lua
hl.monitor({ output = "DP-5", mode = "1920x1080@60", position = "0x0", scale = 1 })

hyprctl reload → panel lights up immediately.

Crucially, switching back to 5120x1440@143.99 then works fine and keeps working. So this is
not a bandwidth or DSC-capability limit on the 144Hz mode — that mode is perfectly usable. It is
a link left un-retrained by the DPMS enable path.

What this is not

• Not a bandwidth/DSC ceiling. 5120x1440@143.99 renders fine once the link is retrained,
  and has run for days.
• Not stale compositor state. Hyprland's reported state was correct and self-consistent throughout.
• Not a DDC/brightness issue. ddcutil reports "No displays implementing DDC/CI found" on
  this monitor, so omarchy-brightness-display has no brightness channel and maps on/off
  directly to DPMS — but that only means DPMS is the actuator, not the cause.
• Not visible in sysfs. /sys/class/drm/card0-DP-5/{enabled,dpms} read disabled / Off
  even on a healthy, actively-rendering output, because atomic KMS never writes those legacy
  attributes. They are not a useful signal here (they cost me significant debugging time).

Suggested fix

On dpms enable, force a full modeset / link retrain for the connector rather than assuming the
previous mode is still valid. A DPMS-off period long enough for the sink to drop the link appears
to leave the enable path committing against a link that was never retrained.

Why this is user-visible on Omarchy

Omarchy's lock screen blanks via DPMS ~5s after locking (idleBlankTimer { interval: 5000 } in
plugins/lock/Service.qml, then omarchy-brightness-display off). That is by design. But on
affected hardware it means: lock the screen, wait 5 seconds, and the display cannot be brought
back by any input — the user is locked out of their own display with no on-screen recovery path.

A defensive workaround on the Omarchy side would be to force a mode change (or an
output disable/enable) as part of omarchy-system-wake when a dpms enable fails to produce a
frame, rather than trusting dpmsStatus.

Note on hyprctl ergonomics (0.56, separate & minor)

• hyprctl dispatch dpms on fails with a lua parse error:
  [string "return hl.dispatch(dpms on)"]:1: ')' expected near 'on'. The correct form is
  hyprctl dispatch 'hl.dsp.dpms({ action = "enable" })'.
• hyprctl dispatch 'hl.dsp.dpms("on")' returns ok but silently ignores the argument and
  toggles, which makes DPMS state bounce confusingly while debugging. Rejecting an
  unrecognised argument would be friendlier than toggling.
• hyprctl keyword monitor ... returns keyword can't work with non-legacy parsers. Use eval.,
  but hl.monitor({...}) via hyprctl eval returns ok while not applying at runtime.
  There appears to be no supported way to change a monitor mode at runtime without editing the
  config file and reloading.

[github-actions]

Users are no longer allowed to open issues themselves, please open a discussion instead.

Please see the wiki on why this is the case.

ATTENTION: If you are opening this issue with AI, please read the AI Policy and ask your AI to read AGENTS.md before opening a discussion. Failure to obey the clauses outlined in either of these documents may result in severe repercussions.

We are volunteers, and we need your cooperation to make the best software we can. Thank you for understanding! ❤️

Open a discussion here