[kstaikov]

Refs #13812, #8580, #13129

Problem

Some HDMI 2.1 monitors drop hotplug-detect when the output is turned off. Behind the lock screen that becomes the loop in #13812: the kernel removes the output, the monitor re-asserts hotplug a few seconds later, Hyprland re-adds it lit, the lock plugin re-arms its blank timer, and the monitor turns off again, every ~40 s for as long as the session is locked. On a current AMD kernel the same monitors then need a long HDMI 2.1 FRL link training after a real standby, which amdgpu 7.2 abandons after one attempt, so wake takes 40–50 s of key-mashing (AMD issue 5709). The kernel-side debounce in #13129 stops the loop but makes the slow wake the normal case, and it deadlocked amdgpu once on my machine (details on that PR).

Change

The display never needs to go off for the monitor to sleep. With omarchy toggle ddc-blank on and only external monitors enabled, omarchy-brightness-display off|on writes the monitor's VCP power mode (D6 = 04 to sleep, 01 to wake) through omarchy-brightness-display-ddc instead of dispatching DPMS. The GPU keeps the link trained, so nothing disconnects, nothing reconnects, and wake is instant. The lock plugin does not change: it already blanks and wakes through that script.

• omarchy-brightness-display-ddc <monitor> off|on writes D6 on the monitor's cached bus. The write is unverified (--noverify), because a monitor that is off no longer answers the read-back and a verified write reports failure for a command it applied.
• omarchy-brightness-display off sleeps every enabled monitor in parallel and falls back to DPMS if any of them refused, so the screen always goes dark. Each monitor that took the sleep is marked asleep under $XDG_RUNTIME_DIR/omarchy-ddc-blank/. on wakes exactly those monitors, whatever the monitor set has become since (a laptop lid reopened before the wake, say), and wakes each once however many wake requests the lock view sends (one per key press and pointer move; a single unlock produced 27 omarchy-system-wake runs in my journal). A monitor that ignores the wake gets a DPMS cycle, which is the modeset it would have had before.
• Blank and wake share a lock. The lock screen starts them without waiting for one another, and a blank that is slow to fail over to DPMS must not turn the displays off after a newer wake has lit them. The lock waits without a timeout: nothing holds it longer than its DDC writes, which the I2C layer bounds, and giving up on a timeout would mean acting without the ordering the lock is for. The lock and the asleep markers live in $XDG_RUNTIME_DIR only; without a private runtime directory the toggle is ignored and DPMS blanks as before.
• The DDC path applies only when every enabled monitor is external (and, on a platform whose displays.conf says so, has a ddc node). A laptop with its lid open keeps DPMS for everything, since the panel has no DDC and mixing the two would leave one display lit.
• omarchy-toggle-ddc-blank and two menu rows under Toggle, with English catalog entries. Off by default; nothing changes for anyone who does not turn it on.

Testing

• test/shell.d/brightness-display-test.sh gains ten cases against a mock compositor that remembers its DPMS state: DPMS stays the default; the toggle writes setvcp D6 04 without a DPMS dispatch; without a runtime directory the toggle is ignored; a built-in panel keeps DPMS; a monitor slept over DDC is woken over DDC even once a built-in panel is back; a burst of wakes writes once and leaves lit displays alone; a refused DDC sleep falls back to DPMS and is then woken with DPMS; an ignored DDC wake gets a DPMS cycle; a wake arriving during a slow, failing blank still ends with the display lit. i18n-test.sh and ./test/cli pass.
• On the machine that motivated this (Ryzen 9 9950X / Radeon 610M, MSI B850M Mortar with HDMI as its only output, Dell U3224KB at 6144x3456@60): 13 hours of use with ten lock cycles including one of 7 h 20 min. Zero Disabling output and zero Connector … disconnected lines in the Hyprland log, 6K@60 intact after every wake, picture back within a second of the first key press. The monitor draws 0.5 W asleep, the same as in DPMS standby.

Caveats

DDC/CI has to be enabled in the monitor's OSD (it is by default on every Dell I have seen). A monitor without DDC/CI simply never takes the command and gets DPMS as before. ddcutil is already a dependency of omarchy-brightness-display-ddc.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge, with the previous ordering-test race fixed.

Summary

Adds an off-by-default ddc-blank toggle that sleeps external monitors over DDC/CI while keeping the video link up.

• External monitors can sleep over DDC/CI when the toggle is on.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Blank request] --> B[Acquire shared lock]
  B --> C{DDC sleep allowed?}
  C -->|Yes| D[Sleep external monitors and save markers]
  C -->|No| E[Blank with DPMS]
  D -->|Any write fails| E
  D --> F[Release lock]
  E --> F
  G[Wake request] --> H[Acquire shared lock]
  H --> I[Wake monitors listed in markers]
  I --> J[Use DPMS fallback if needed]
  J --> K[Release lock]

Loading

_{Reviews (5) · Last reviewed commit: "Start the wake in the ordering test only..." · Reviewed by Greptile}

[chessing234]

flock -w 10 || true keeps going when the lock is not held. blank and wake are supposed to share that lock so a slow blank cannot turn the displays off after a newer wake, and the timeout path skips it.

[kstaikov]

Thanks, that was a hole: the timeout path went ahead without the lock, which is the exact race the lock is there for. The lock is now taken without a timeout, so a wake always runs after the blank in flight and a blank after the wake in flight. Nothing holds it longer than its DDC writes, which the I2C layer bounds, and both processes are started asynchronously by the lock plugin, so a wait never blocks the shell. I checked this on the hardware by holding the lock from another process for three seconds: the wake waited the three seconds, then lit the monitor. Also moved the lock and the markers out of the /tmp fallback per Greptile's finding. Fixed in 9b2e1d3.

(Prepared with Claude's help; reviewed and posted by me.)