Proof Portal

Sign in
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-2164GitHub issuePublicDecided· Out of scope

Brightness keys do nothing on external monitors behind a USB-C dock (DP MST)

Reported by grivera82 · filed Oct 2, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 3 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

Brightness keys do nothing on external monitors behind a USB-C dock (DP MST)revision 1 · captured 2026-10-02 01:21 UTC via poll

System details

ASUS Vivobook S 16 M5606KA (Ryzen AI 7 350, Radeon 860M, amdgpu), ASUS ProArt PA329CRV over USB-C (DP MST), Omarchy 4.0.4-1, ddcutil 2.2.7

What's wrong?

On an external monitor connected over DP MST, omarchy-brightness-display can't read or change the brightness. The brightness keys and the shell's brightness slider do nothing. The monitor supports DDC/CI, and that path to it works.

$ omarchy-brightness-display --no-osd --monitor DP-8
$ echo $?
1

Cause

omarchy-brightness-display-ddc finds the bus with ddcutil detect, which never lists the monitor. With MST, the monitor is on a virtual connector (DP-8) that has no I2C bus of its own. The DDC channel goes through the AUX bus of the physical port (DP-1, /dev/i2c-13), and the kernel reports that port as disconnected:

card1-DP-1  status=disconnected  i2c-13 (AMDGPU DM aux hw bus 2)
card1-DP-8  status=connected     (no i2c bus)

ddcutil maps i2c-13 to DP-1, sees it disconnected, and refuses the bus, even when you name it explicitly:

$ ddcutil --bus 13 --skip-ddc-checks getvcp 10
No monitor detected on bus /dev/i2c-13
$ ddcutil --bus 13 --skip-ddc-checks --disable-try-get-edid-from-sysfs getvcp 10
Error opening Display_Ref[1:bus /dev/i2c-13]: DDCRC_DISCONNECTED

DDC/CI on that bus does reach the monitor. Reading the EDID at 0x50 on i2c-13 returns the PA329CRV's EDID, and VCP 0x10 get/set at 0x37 works. I use a ~200-line standard-library Python script that does this. It finds the bus by matching the EDID read over I2C against /sys/class/drm/card1-DP-8/edid, caches the result, and sends the DDC/CI brightness get/set itself. It reads in ~80 ms.

Steps to reproduce

  1. Connect a DDC/CI-capable monitor through a USB-C dock or an MST hub, so it shows up as DP-N with N above the physical port count.
  2. Press a brightness key with that monitor focused, or run omarchy-brightness-display --monitor DP-N. Nothing changes, and the command exits 1.
  3. ddcutil detect lists only the laptop panel.

Possible fix

When ddcutil detect doesn't map the monitor, fall back to matching the connector's sysfs EDID against the EDID read from each display I2C bus (AMDGPU DM aux, DPMST, i915, …), then send the DDC/CI brightness get/set directly, since ddcutil refuses that bus. I'm happy to open a PR with this if you want it.

View raw text
### System details

ASUS Vivobook S 16 M5606KA (Ryzen AI 7 350, Radeon 860M, amdgpu), ASUS ProArt PA329CRV over USB-C (DP MST), Omarchy 4.0.4-1, ddcutil 2.2.7

### What's wrong?

On an external monitor connected over DP MST, `omarchy-brightness-display` can't read or change the brightness. The brightness keys and the shell's brightness slider do nothing. The monitor supports DDC/CI, and that path to it works.

```
$ omarchy-brightness-display --no-osd --monitor DP-8
$ echo $?
1
```

**Cause**

`omarchy-brightness-display-ddc` finds the bus with `ddcutil detect`, which never lists the monitor. With MST, the monitor is on a virtual connector (`DP-8`) that has no I2C bus of its own. The DDC channel goes through the AUX bus of the physical port (`DP-1`, `/dev/i2c-13`), and the kernel reports that port as `disconnected`:

```
card1-DP-1  status=disconnected  i2c-13 (AMDGPU DM aux hw bus 2)
card1-DP-8  status=connected     (no i2c bus)
```

ddcutil maps `i2c-13` to `DP-1`, sees it disconnected, and refuses the bus, even when you name it explicitly:

```
$ ddcutil --bus 13 --skip-ddc-checks getvcp 10
No monitor detected on bus /dev/i2c-13
$ ddcutil --bus 13 --skip-ddc-checks --disable-try-get-edid-from-sysfs getvcp 10
Error opening Display_Ref[1:bus /dev/i2c-13]: DDCRC_DISCONNECTED
```

DDC/CI on that bus does reach the monitor. Reading the EDID at `0x50` on `i2c-13` returns the PA329CRV's EDID, and VCP `0x10` get/set at `0x37` works. I use a ~200-line standard-library Python script that does this. It finds the bus by matching the EDID read over I2C against `/sys/class/drm/card1-DP-8/edid`, caches the result, and sends the DDC/CI brightness get/set itself. It reads in ~80 ms.

**Steps to reproduce**

1. Connect a DDC/CI-capable monitor through a USB-C dock or an MST hub, so it shows up as `DP-N` with N above the physical port count.
2. Press a brightness key with that monitor focused, or run `omarchy-brightness-display --monitor DP-N`. Nothing changes, and the command exits 1.
3. `ddcutil detect` lists only the laptop panel.

**Possible fix**

When `ddcutil detect` doesn't map the monitor, fall back to matching the connector's sysfs EDID against the EDID read from each display I2C bus (`AMDGPU DM aux`, `DPMST`, `i915`, …), then send the DDC/CI brightness get/set directly, since ddcutil refuses that bus. I'm happy to open a PR with this if you want it.

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 20:30 UTC