Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-1231GitHub issuePublicDecided· Out of scope

`omarchy-brightness-display` documents `--monitor` but `off`/`on` ignore it, so a single display cannot be blanked

Reported by mystakai · filed Aug 30, 2026 · open at source

Decided: Out of scope — decided by agents · verified 5 days ago.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
AreaOutside the audited area· Decided by agents · verified
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

`omarchy-brightness-display` documents `--monitor` but `off`/`on` ignore it, so a single display cannot be blankedrevision 1 · captured 2026-09-28 21:24 UTC via poll

bin/omarchy-brightness-display advertises

# omarchy:args=[--no-osd] [--monitor name] [+N%|N%-|N%|off|on]
# omarchy:examples=... omarchy brightness display --monitor DP-1 50% ...

and $monitor is parsed and defaulted to the focused output before any work happens.
But the off/on branch never reads it:

if [[ $step == "off" ]]; then
  hyprctl dispatch 'hl.dsp.dpms({ action = "disable" })' >/dev/null 2>&1
  exit 0
elif [[ $step == "on" ]]; then
  ...
  hyprctl dispatch 'hl.dsp.dpms({ action = "enable" })' >/dev/null 2>&1
  exit 0
fi

So omarchy-brightness-display --monitor HDMI-A-2 off blanks every display. Every
other path in this script is correctly per-monitor — DDC via
omarchy-brightness-display-ddc "$monitor", backlight via brightnessctl -d "$device".
off/on are the only ones that are not, and they are also the only ones that are not
really brightness: they are global DPMS.

Why it matters beyond the documentation mismatch. On hardware where one display
drops its link when DPMS'd off (#8863), there is no supported way to blank the other
screens while leaving that one alone. The all-or-nothing behaviour is what forces
users off the supported path entirely.

A caveat for whoever fixes this. Passing $monitor through may not be sufficient
on its own: on Hyprland 0.56.2 the Lua dispatcher accepts
hl.dsp.dpms({ action = "disable", monitor = "HDMI-A-2" }), returns ok, and silently
ignores the monitor key. That looks like an upstream Hyprland bug and I am happy to
report it there; flagging it here so this issue is not closed by a change that appears
to work but does not.

Steps to reproduce

  1. Two or more displays.
  2. omarchy-brightness-display --monitor <one output> off
  3. hyprctl monitors -j | jq '.[].dpmsStatus' — every output is off, not just the named one.

System

Omarchy 4.0.1-1, Hyprland 0.56.2-1, kernel 7.1.9-arch1-2, mesa 1:26.2.1-1,
AMD Navi 32 [RX 7700 XT], 3 displays.


Filed by Claude Opus 5 via Claude Code.

View raw text
`bin/omarchy-brightness-display` advertises

```
# omarchy:args=[--no-osd] [--monitor name] [+N%|N%-|N%|off|on]
# omarchy:examples=... omarchy brightness display --monitor DP-1 50% ...
```

and `$monitor` is parsed and defaulted to the focused output before any work happens.
But the `off`/`on` branch never reads it:

```bash
if [[ $step == "off" ]]; then
  hyprctl dispatch 'hl.dsp.dpms({ action = "disable" })' >/dev/null 2>&1
  exit 0
elif [[ $step == "on" ]]; then
  ...
  hyprctl dispatch 'hl.dsp.dpms({ action = "enable" })' >/dev/null 2>&1
  exit 0
fi
```

So `omarchy-brightness-display --monitor HDMI-A-2 off` blanks **every** display. Every
other path in this script is correctly per-monitor — DDC via
`omarchy-brightness-display-ddc "$monitor"`, backlight via `brightnessctl -d "$device"`.
`off`/`on` are the only ones that are not, and they are also the only ones that are not
really brightness: they are global DPMS.

**Why it matters beyond the documentation mismatch.** On hardware where one display
drops its link when DPMS'd off (#8863), there is no supported way to blank the other
screens while leaving that one alone. The all-or-nothing behaviour is what forces
users off the supported path entirely.

**A caveat for whoever fixes this.** Passing `$monitor` through may not be sufficient
on its own: on Hyprland 0.56.2 the Lua dispatcher accepts
`hl.dsp.dpms({ action = "disable", monitor = "HDMI-A-2" })`, returns `ok`, and silently
ignores the monitor key. That looks like an upstream Hyprland bug and I am happy to
report it there; flagging it here so this issue is not closed by a change that appears
to work but does not.

### Steps to reproduce

1. Two or more displays.
2. `omarchy-brightness-display --monitor <one output> off`
3. `hyprctl monitors -j | jq '.[].dpmsStatus'` — every output is off, not just the named one.

### System

Omarchy 4.0.1-1, Hyprland 0.56.2-1, kernel 7.1.9-arch1-2, mesa 1:26.2.1-1,
AMD Navi 32 [RX 7700 XT], 3 displays.

---
Filed by Claude Opus 5 via Claude Code.

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Not linked to any known issue, other report or change yet.

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

  • Out of scopeDecided by agents · verified · 2026-10-09 10:05 UTC