On a Dell XPS 14 DA14260 with the 2880x1800 OLED panel, brightness control has no effect on the internal display. `brightnessctl` and the brightness keys both report success, and `/sys/class/backlight/intel_backlight/actual_brightness` tracks every value written — but the panel stays at one brightness.

Booting with `xe.enable_dpcd_backlight=1` fixes it completely.

### Not all XPS 14s are affected

Worth stating up front, since this won't reproduce on every XPS 14: the machine ships with either a 1920x1200 IPS or a 2880x1800 OLED panel, and I've only seen this on the OLED. To check which panel a given unit has:

```bash
od -An -tx1 -j8 -N2 /sys/class/drm/card*-eDP-*/edid | tr -d ' \n'   # affected panel reports 30e4
cat /sys/class/backlight/intel_backlight/max_brightness             # 512 here
```

If brightness already works on your unit, I'd be curious what those two print — if it reports `30e4` and works fine, then my diagnosis below is incomplete and I'd want to know.

### Why the kernel's own suggestion doesn't work

The panel's EDID carries no HDR static metadata, so the kernel prints:

```
xe 0000:00:02.0: [drm] [CONNECTOR:512:eDP-1] Panel is missing HDR static metadata.
Possible support for Intel HDR backlight interface is not used. If your backlight
controls don't work try booting with i915.enable_dpcd_backlight=3.
```

That hint is misleading twice over on this hardware:

1. **The module is `xe`, not `i915`** on Panther Lake.
2. **`=3` does not fix it.** It forces the Intel HDR backlight interface, which this panel accepts writes on but never acts on.

I read the DPCD registers over `/dev/drm_dp_aux0` under both values to confirm:

| | `=3` (Intel HDR) | `=1` (VESA DPCD) |
|---|---|---|
| Brightness delivered to panel | yes — `0x354`/`0x355` track sysfs as nits | yes — `0x734` tracks sysfs in millinits |
| Panel acts on it | **no** — `0x357` `BRIGHTNESS_CONTROL_ENABLE` stays clear | **yes** |
| Result | writes accepted, panel frozen | works across the full range |

Under `=1`, `0x721` reads `0x82`: AUX control mode plus `PANEL_LUMINANCE_CONTROL_ENABLE`. So brightness rides the *luminance* path rather than the legacy `0x722`/`0x723` registers, which stay parked at `0xffff` — expected on this panel, not a fault. Measured: 100% → `0x07d000` (512000 millinits), 40% → `0x0320c8` (205000).

One thing that is *not* a useful signal: the `missing HDR static metadata` warning disappears under both `=1` and `=3`, and `max_brightness` reads 512 under both. Neither distinguishes a working interface from a broken one — the only reliable test is whether the panel visibly dims.

### Environment

- Dell XPS 14 DA14260, LG Display panel, EDID id `30e4`
- `linux-ptl` 7.1.5-arch1-1-ptl, `xe` driver, Panther Lake (device ID b080)
- Omarchy 4 (`omarchy-dev` 4.0.0.r1585.g99293aa-1)
- Applied via `KERNEL_CMDLINE[default]+=" xe.enable_dpcd_backlight=1"` in a `/etc/limine-entry-tool.d/` drop-in, then `limine-update`

### Possible fix

There's an existing precedent for exactly this shape of fix in `install/hardware/asus/fix-asus-ptl-display-backlight.sh` (#5620), and the repo already ships an `omarchy-hw-dell-xps-oled` detector that matches this panel but currently has no callers.

I had a patch along those lines in #6675 (closed) if it's useful as a reference — happy to leave the decision on whether Omarchy should carry this at all, since it's arguably a kernel-side quirk.