## What happens

I have three screens: a laptop panel (eDP-1), a Samsung U32R59x on the HDMI port (HDMI-A-1), and a Lenovo T25d in portrait driven from a laptop USB-C port into the monitor HDMI input, over a USB-C to HDMI cable. DRM and Hyprland name that third one DP-1, since the USB-C side is DisplayPort alt mode.

Every time I open the display module in the bar, or run `omarchy brightness display --monitor DP-1`, the Lenovo goes completely black for two to three seconds and then comes back on its own. Nothing is changed on it: something in that chain, the monitor or the converter in the cable, drops the signal and re-trains the link when it is probed.

It happens on every single open, not only the first one.

A side effect: the blanking looks like an unplug and replug, so `omarchy-hyprland-monitor-clamshell` fires twice right after each time.

## Why

`omarchy-brightness-display-ddc` caches the I2C bus per connector in `$XDG_RUNTIME_DIR/omarchy-brightness-display-ddc/<connector>.bus`, so that the expensive `ddcutil --skip-ddc-checks detect --brief` (which walks every attached display's control channel) only runs when the bus is not known yet.

There is an "unavailable" negative cache with a 60 second window, but it is only written when `detect_bus` finds nothing at all:

```bash
bus="$(detect_bus)" || return 1
if [[ ! $bus =~ ^[0-9]+$ ]]; then
  cache_unavailable
  return 1
fi
```

The Lenovo is not that case. It is found by `detect`, so a bus number is cached, and then it does not answer the brightness read. That path deletes the cache file instead of remembering the failure:

```bash
bus="$(find_bus)" || return 1
values="$(read_vcp "$bus")" || {
  rm -f "$cache_file"
  return 1
}
```

So nothing is remembered, and the next open runs the full `detect` scan again, which disturbs the monitor again. A screen that is visible to DDC but has no readable brightness gets rescanned forever.

For contrast, the Samsung works fine and keeps its cache entry (`4 100 <timestamp>`), so it is only the monitor without readable brightness that pays this, repeatedly.

## Expected

A monitor that has been found once to have no readable DDC brightness should be remembered as unavailable, the same as one that is not found at all, so it is probed once rather than on every open.

## Steps to reproduce

1. Attach a monitor that answers `ddcutil detect` but not `getvcp 10`.
2. Open the display module in the bar, or run `omarchy brightness display --monitor <that connector>`.
3. The monitor blanks and re-syncs. Repeat and it blanks again every time.
4. `ls $XDG_RUNTIME_DIR/omarchy-brightness-display-ddc/` shows no entry for that connector, so the next call rescans.

## Possible fix

In `read_brightness`, call `cache_unavailable` instead of `rm -f "$cache_file"` when `read_vcp` fails, or keep the detected bus and record that VCP 10 is unsupported on it. Either way the full `detect` scan stops running on every open.

## System

- Omarchy 4.0.0rc4-1 (rc / edge)
- Hyprland v0.56.2, kernel 7.1.8-arch1-3
- AMD Radeon 880M/890M (Strix), amdgpu
- ddcutil 2.2.7
- Affected monitor: Lenovo LEN T25d-10, portrait, laptop USB-C to monitor HDMI input, named DP-1
- Working monitor: Samsung U32R59x on the laptop HDMI port, named HDMI-A-1

I also tried the ddcutil-side workaround of excluding just that model with `--ignore-mmid` in `~/.config/ddcutil/ddcutilrc`, but I could not get ddcutil 2.2.7 to accept the syntax for a model name containing a space, so that route did not help.