Fall back to the kernel backlight for an all-in-one's DP panel

[omarchybot]

omarchy-brightness-display picks DDC/CI for any connector not named eDP, LVDS or DSI. An all-in-one wires its built-in panel to a DisplayPort connector, so an iMac's panel is DP-1 or DP-3, goes to DDC/CI, which it does not answer, and brightness fails outright: the Display panel shows FIXED BRIGHTNESS, the brightness keys do nothing, and the script exits 1 while a working backlight sits in /sys/class/backlight. Two reporters see it on different iMacs, one on nouveau and one on Intel graphics alone.

DDC is still tried first. A display moves to the kernel backlight only when all of these hold: its connector is DP-, hyprctl monitors all lists it and nothing else, omarchy-hw-display finds a backlight, and a DDC read of it fails. With one display and one backlight the backlight can only be that panel's. Disabled and mirrored outputs are listed by monitors all, so a laptop with its lid shut keeps its external monitor on DDC. The fallback turns on a failed read rather than a failed write, so a monitor that can be read stays on DDC when a write fails.

What this does not cover, deliberately: an all-in-one with a second display attached still sends its panel to DDC, because nothing maps a firmware backlight such as acpi_video0 to a connector, and this does not guess. The residual risk is a desktop exposing an unrelated backlight next to a single DP monitor that cannot be read over DDC, which today has no brightness at all and would now move that backlight. A transient read failure on such a desktop sends that one press to the backlight too. On the reported iMacs the panel is listed by ddcutil but does not answer, and quattro drops the bus cache after a failed read, so each press probes again. That cost is unchanged from today, and #14525 caches the failure.

#12267 also routes all-in-ones to the backlight, but only when ddcutil detect does not list the connector, and both reporters' panels are listed, so it does not fix these machines. #14323 uses a backlight attached to the connector itself, which an iMac's acpi_video0 is not. The routing here is @roju's from the issue, with the DDC-first ordering added.

The new cases in test/shell.d/brightness-display-test.sh fail with the fix reverted and pass with it, on a worker built from the Omarchy ISO. They cover an unresponsive lone DP panel falling back for reads and writes, a lone DP monitor that answers DDC staying on it with a backlight present, a failed DDC write leaving the backlight alone, a DP display beside another getting no fallback, and a lone virtual output leaving the backlight alone. No all-in-one was available, so the fix still needs confirming on one of the reporters' machines. Written by Claude Opus 5.5 and reviewed over four rounds by Codex Medium, whose findings shaped the DDC-first ordering, the read-not-write rule and the DP- restriction. Its last round found nothing open.

Fixes #8015

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 4/5

[Medium impact] Changes brightness control fallback logic for display panels.

The PR appears safe to merge, with a non-blocking concern about unnecessary DDC reads.

Findings

1.  DDC reads run twice ▶

Summary

Adds a kernel-backlight fallback for a lone DP-* panel when a backlight exists and DDC cannot read brightness.

• Keeps readable displays on DDC and leaves Apple routing unchanged.
• Adds tests for fallback, working DDC, failed writes, multiple outputs, missing backlights, and virtual outputs.
• One non-blocking concern: successful DDC probes add unnecessary hardware reads.

omarchybot explicitly acknowledged and accepted fallback being unavailable with a second output, possible use of an unrelated backlight, and fallback after a transient read failure. The stated reason for excluding multiple outputs is that firmware backlights cannot reliably be mapped to connectors.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Read or adjust brightness] --> B{Apple display?}
  B -->|Yes| C[Apple control]
  B -->|No| D{Internal connector?}
  D -->|Yes| E[Kernel backlight]
  D -->|No| F{Lone DP output and backlight exists?}
  F -->|No| G[Requested DDC operation]
  F -->|Yes| H{DDC read succeeds?}
  H -->|No| E
  H -->|Yes| G

Loading

_{Reviews (1) · Last reviewed commit: "Fall back to the kernel backlight for an..." · Reviewed by Greptile}

[greptile-apps]

DDC reads run twice

For a lone DP-* display with a kernel backlight and working DDC, this probe discards a successful brightness read before the requested operation runs. Queries and relative changes then issue a second getvcp. Absolute changes also gain an unnecessary read even when the range is already cached.

These extra hardware reads slow brightness adjustments. Reuse the successful probe for the requested operation, and add a read-count check to the lone-DP test.