## System details

Apple iMac13,1, Intel i5-3330S, NVIDIA GK107M [GeForce GT 640M Mac Edition] on nouveau, Omarchy 4.0.0-1, kernel 7.1.8-arch1-3. Single built-in panel, reported by Hyprland as `DP-1` (`make: Apple Computer Inc`, `model: iMac`). `/sys/class/backlight/acpi_video0` exists and works.

## What's wrong

`omarchy-brightness-display` decides between the kernel backlight and DDC/CI purely from the connector name:

```bash
monitor_is_internal() {
  [[ $monitor =~ ^(eDP|LVDS|DSI)- ]]
}

use_ddc_display() {
  [[ -n $monitor ]] && ! monitor_is_internal
}
```

All-in-ones wire their built-in panel to a DisplayPort connector, so it is named `DP-1` and classified as external. Brightness is then attempted over DDC/CI, which a built-in panel does not answer, so the script exits 1 — **even though a working backlight device is sitting right there in `/sys/class/backlight`.**

The visible symptoms:

- Display panel shows `FIXED BRIGHTNESS` with no slider, because `omarchy-monitor-state` gets an empty first line from `omarchy-brightness-display --monitor DP-1`
- `XF86MonBrightnessUp`/`Down` do nothing
- `omarchy-brightness-display` exits 1 with no output

The backlight itself is fine — `brightnessctl -d acpi_video0 set 50%` changes the panel immediately. Only the routing is wrong.

## Steps to reproduce

On any machine whose only display is on a non-`eDP`/`LVDS`/`DSI` connector while `/sys/class/backlight` is populated:

```bash
$ ls /sys/class/backlight/
acpi_video0
$ hyprctl monitors -j | jq -r '.[].name'
DP-1
$ omarchy-brightness-display; echo "exit=$?"
exit=1                     # expected: the current brightness percentage
```

## Fix

Prefer the kernel backlight when the named monitor is the machine's only display and a backlight device exists. In that situation the backlight can only belong to that panel, so no name heuristic is needed.

```diff
--- a/bin/omarchy-brightness-display
+++ b/bin/omarchy-brightness-display
@@ -39,8 +39,19 @@ use_apple_display() {
   omarchy-hyprland-monitor-focused-apple "$monitor"
 }
 
+# All-in-one desktops wire their built-in panel to a DisplayPort connector, so
+# the output name carries no hint that it is internal. When the named monitor is
+# the machine's only display and the kernel exposes a backlight, that backlight
+# drives this panel -- prefer it over DDC/CI, which built-in panels do not answer.
+monitor_is_only_panel() {
+  local monitors
+  monitors="$(hyprctl monitors all -j 2>/dev/null)" || return 1
+  jq -e --arg monitor "$monitor" 'length == 1 and .[0].name == $monitor' <<<"$monitors" >/dev/null 2>&1 &&
+    omarchy-hw-display >/dev/null 2>&1
+}
+
 use_ddc_display() {
-  [[ -n $monitor ]] && ! monitor_is_internal
+  [[ -n $monitor ]] && ! monitor_is_internal && ! monitor_is_only_panel
 }
```

This also fixes the Display panel and the brightness keys with no further change, because both route through this script.

## What it does not change

I stubbed `hyprctl` and the `omarchy-*` helpers and checked which backend each machine shape selects, before and after:

| Machine shape | Before | After |
|---|---|---|
| All-in-one, single DP panel, backlight present | DDC ✗ | **backlight ✓** |
| Laptop, internal `eDP-1` focused | backlight | backlight |
| Laptop, external `DP-1` focused | DDC | DDC |
| Laptop, lid shut, external focused | DDC | DDC |
| Desktop, one DDC monitor, no backlight device | DDC | DDC |
| All-in-one plus a second monitor | DDC | DDC |
| Apple Studio Display | asdcontrol | asdcontrol |

Only the first row changes. The laptop-with-external case is preserved by `hyprctl monitors all`, which keeps listing the internal panel even when it is disabled, so `length == 1` stays false.

## Known limitation

An all-in-one with a second monitor attached still sends its built-in panel to DDC/CI, because nothing maps a backlight device back to a connector — `/sys/class/backlight/acpi_video0/device` resolves to the GPU, not the output. This patch deliberately does not guess.

If you would rather fix that case too, the general alternative is to drop the pre-classification and fall back instead: attempt DDC, and if it fails while `omarchy-hw-display` succeeds, use the backlight. That covers every shape above, at the cost of letting brightness keys move the internal backlight when an external monitor's DDC is merely flaky. I went with the narrower rule; happy to send the other one if you prefer it.

The one residual risk in the narrow rule is a desktop that exposes a spurious `acpi_video0` while driving a single real DDC monitor. That would newly route to the backlight. I have not found such a machine, but I cannot rule it out.

## Not Apple-specific

Worth saying plainly: this is not an Apple bug and the fix is not Apple-specific. Any machine that exposes a backlight while its only panel sits on a `DP-` connector hits it. On this particular iMac a patched nouveau is what makes `acpi_video0` appear at all, since upstream nouveau only registers a backlight for `LVDS`/`eDP` connectors — but Omarchy's routing bug is independent of that, and bites as soon as any backlight device exists by whatever route.