Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
Display backlight non-functional on Dell XPS Panther Lake (nondeterministic AUX/PWM negotiation at boot) — needs xe.enable_dpcd_backlight=1
Reported by RodriMora · filed Sep 13, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #6676 (R-1875). GitHub close reason: completed.
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?
- Not yet mapped to any requirement or component.
- 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?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
On a Dell XPS 14 (Panther Lake, Core Ultra X7 358H / Arc B390 iGPU, linux-ptl 7.2.3-arch1-1, omarchy 4.0.3), screen brightness is dead on some boots: keys, the shell slider, and the OSD all work, intel_backlight sysfs writes succeed, but the panel doesn't respond — brightness is effectively fixed at whatever the panel was left at.
Root cause (matches install/hardware/asus/fix-asus-ptl-display-backlight.sh verbatim, which is currently allow-listed to ExpertBook B9406 / Zenbook UX5406AA only): the panel wants DPCD AUX backlight, but on failing boots the xe driver falls back to PWM.
Evidence of nondeterminism across boots (same kernel, same cmdline):
- Broken boots log at boot:
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.— and exposemax_brightness=192000(raw PWM levels). Boots with this message in the journal: Aug 31, Sep 6, Sep 8, Sep 9 (bright still broken after suspend/resume cycles — sysfs writes changed values, screen didn't respond, verified live). - Healthy boots log nothing and expose
max_brightness=512(AUX levels) — brightness works. Healthy boots: Sep 2, Sep 13. - A reboot alone fixes it or doesn't, depending on whether the probe wins the race this boot. Verified today: after a fresh boot,
max_brightnessswitched 192000 → 512 and brightness works with no config change.
Fix: adding xe.enable_dpcd_backlight=1 via a Limine drop-in (same as the ASUS PTL script) forces AUX mode and removes the race. Since Dell XPS PTL machines already get linux-ptl + fred=on via ptl-kernel.sh, extending the backlight fix to them (omarchy-hw-match "XPS" && omarchy-hw-intel-ptl) would cover this — happy to send a PR.
omarchy version: 4.0.3-1. Kernel: linux-ptl 7.2.3.arch1-1.
Filed by GLM (Z.ai) via pi coding agent, with issue text reviewed and approved by the machine owner.
View raw text
On a Dell XPS 14 (Panther Lake, Core Ultra X7 358H / Arc B390 iGPU, `linux-ptl` 7.2.3-arch1-1, omarchy 4.0.3), screen brightness is dead on some boots: keys, the shell slider, and the OSD all work, `intel_backlight` sysfs writes succeed, but the panel doesn't respond — brightness is effectively fixed at whatever the panel was left at. **Root cause** (matches `install/hardware/asus/fix-asus-ptl-display-backlight.sh` verbatim, which is currently allow-listed to ExpertBook B9406 / Zenbook UX5406AA only): the panel wants DPCD AUX backlight, but on failing boots the `xe` driver falls back to PWM. **Evidence of nondeterminism across boots (same kernel, same cmdline):** - Broken boots log at boot: `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.` — and expose `max_brightness=192000` (raw PWM levels). Boots with this message in the journal: Aug 31, Sep 6, Sep 8, Sep 9 (bright still broken after suspend/resume cycles — sysfs writes changed values, screen didn't respond, verified live). - Healthy boots log nothing and expose `max_brightness=512` (AUX levels) — brightness works. Healthy boots: Sep 2, Sep 13. - A reboot alone fixes it or doesn't, depending on whether the probe wins the race this boot. Verified today: after a fresh boot, `max_brightness` switched 192000 → 512 and brightness works with no config change. **Fix:** adding `xe.enable_dpcd_backlight=1` via a Limine drop-in (same as the ASUS PTL script) forces AUX mode and removes the race. Since Dell XPS PTL machines already get `linux-ptl` + `fred=on` via `ptl-kernel.sh`, extending the backlight fix to them (`omarchy-hw-match "XPS" && omarchy-hw-intel-ptl`) would cover this — happy to send a PR. `omarchy version`: 4.0.3-1. Kernel: `linux-ptl 7.2.3.arch1-1`. *Filed by GLM (Z.ai) via pi coding agent, with issue text reviewed and approved by the machine owner.*
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.
No decision has been recorded yet.