Proof Portal

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-762GitHub issuePublicDecided· Out of scope

Panel Replay desktop lag on Dell XPS 14 after 4.0.3 update; reproduces on 7.2.4 base kernel

Reported by rbulcher · filed Sep 9, 2026 · 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

Panel Replay desktop lag on Dell XPS 14 after 4.0.3 update; reproduces on 7.2.4 base kernelrevision 1 · captured 2026-09-28 21:23 UTC via poll

System details

  • Dell XPS 14 DA14260; Intel Core Ultra X7 358H; 32 GB RAM.
  • Intel Panther Lake Arc B390 (8086:b080), xe driver.
  • Non-OLED internal panel: LG Display 0x07C8, eDP-1, 1920×1200 at 120.043 Hz, scale 1.25; VRR disabled, hardware cursor enabled.
  • Omarchy 4.0.3-1, Hyprland 0.56.2-2, Mesa 1:26.2.2-1.
  • Last tested good with Panel Replay enabled: 7.1.8-arch1-2-ptl.
  • Affected: 7.2.3-arch1-1-ptl and maintainer-provided base 7.2.4-1-omarchy.

What's wrong?

After updating Omarchy 4.0.2 → 4.0.3 and rebooting, pointer movement, workspace animations and terminal rendering became visibly sluggish despite the display reporting approximately 120 Hz. Expected behavior is the smooth motion observed before the update.

I isolated the kernel change by booting the old 7.1.8 PTL kernel on the current root/userspace, not just rolling back to a snapshot. With Panel Replay enabled, that comparison was smooth; its captured installed package list was identical to the affected current-userspace capture.

Completed comparisons

Kernel / settingDriver-confirmed modeResult
7.1.8 PTL, current userspace, debug 0Panel Replay enabledSmooth
7.2.3 PTL, debug 0Panel Replay enabledSluggish
7.2.3 PTL, debug 1PSR disabledSmooth
7.2.3 PTL, debug 64PSR1 enabled, Panel Replay disabledSmooth
7.2.3 PTL, return to debug 0 in same sessionPanel Replay enabledSluggishness immediately returned
7.2.3 PTL, normal reboot with xe.enable_panel_replay=0PSR1 enabledSmooth
Krzysztof's 7.2.4-1 base build, debug 0Panel Replay enabledSluggish
Same 7.2.4 session, debug 64PSR1 enabled, Panel Replay disabledSmooth again

The 7.2.3 live comparison held the kernel, applications and power profile constant; custom shell plugins were disabled and LibrePods stopped. Restoring plugins and Balanced mode with the workaround retained smoothness. Those plugins are not required to trigger this symptom.

The existing xe.enable_psr2_sel_fetch=0 setting was retained throughout these comparisons. The 7.2.4 test explicitly omitted the persistent Panel Replay disable option. Its signed manifest and both package checksums were verified; this was linux-omarchy base, not BORE/MuQSS/T2, from source revision c584bb66097936f689ad0a4808c88f9a8f3a29f7.

Reproduction on this machine

  1. Boot either affected kernel with the existing selective-fetch setting above, without xe.enable_panel_replay=0.
  2. Confirm Panel Replay is active in /sys/kernel/debug/dri/0/i915_edp_psr_status.
  3. Move the pointer, change workspaces and observe terminal rendering: motion feels sluggish.
  4. Disable only Panel Replay and inspect the resulting mode:
echo 64 | sudo tee /sys/kernel/debug/dri/0/i915_edp_psr_debug
sudo cat /sys/kernel/debug/dri/0/i915_edp_psr_status

The driver reports PSR1 enabled, and motion becomes smooth. On 7.2.3, writing 0 back reproduced the lag immediately. These are direct observations of the physical display, not measured FPS benchmarks.

Logs and workaround

All three tested kernel versions logged:

Applying Panel Replay ALPM cursor lag workaround

The original affected 7.2.3 boot had 86 PSR timeout messages, predominantly:

Timed out waiting for PSR Idle for re-enable

The old-kernel captures had none. However, the later live comparison reproduced lag without new timeout messages, so those errors are supporting evidence rather than a required symptom.

The verified persistent workaround on normal 7.2.3 PTL is /etc/limine-entry-tool.d/xe-panel-replay-workaround.conf containing:

KERNEL_CMDLINE[default]+=" xe.enable_panel_replay=0"

Rebuild with limine-mkinitcpio linux-ptl and reboot. The runtime parameter was verified as 0, debug override remained 0, and the driver reported PSR1 enabled. No daemon is needed. Battery impact has not been measured.

Full completed-test report: https://mdpad.live/d/xoVGZvOVfMaXw0W1nCI6e

Related reports: #6853 (XPS 13 / Wildcat Lake), #6768 (earlier XPS 16 / Panther Lake issue). This report adds an XPS 14 kernel-only comparison and reproduction on the maintainer-provided 7.2.4 base build; I have not established that their exact underlying cause is identical.

The tests establish a Panel Replay-dependent regression on this machine and a working workaround. The exact offending commit has not been identified.

View raw text
### System details

- Dell XPS 14 DA14260; Intel Core Ultra X7 358H; 32 GB RAM.
- Intel Panther Lake Arc B390 (`8086:b080`), `xe` driver.
- Non-OLED internal panel: LG Display `0x07C8`, eDP-1, 1920×1200 at 120.043 Hz, scale 1.25; VRR disabled, hardware cursor enabled.
- Omarchy `4.0.3-1`, Hyprland `0.56.2-2`, Mesa `1:26.2.2-1`.
- Last tested good with Panel Replay enabled: `7.1.8-arch1-2-ptl`.
- Affected: `7.2.3-arch1-1-ptl` and maintainer-provided base `7.2.4-1-omarchy`.

### What's wrong?

After updating Omarchy 4.0.2 → 4.0.3 and rebooting, pointer movement, workspace animations and terminal rendering became visibly sluggish despite the display reporting approximately 120 Hz. Expected behavior is the smooth motion observed before the update.

I isolated the kernel change by booting the old 7.1.8 PTL kernel on the **current root/userspace**, not just rolling back to a snapshot. With Panel Replay enabled, that comparison was smooth; its captured installed package list was identical to the affected current-userspace capture.

#### Completed comparisons

| Kernel / setting | Driver-confirmed mode | Result |
|---|---|---|
| 7.1.8 PTL, current userspace, debug 0 | Panel Replay enabled | Smooth |
| 7.2.3 PTL, debug 0 | Panel Replay enabled | Sluggish |
| 7.2.3 PTL, debug 1 | PSR disabled | Smooth |
| 7.2.3 PTL, debug 64 | PSR1 enabled, Panel Replay disabled | Smooth |
| 7.2.3 PTL, return to debug 0 in same session | Panel Replay enabled | Sluggishness immediately returned |
| 7.2.3 PTL, normal reboot with `xe.enable_panel_replay=0` | PSR1 enabled | Smooth |
| Krzysztof's 7.2.4-1 base build, debug 0 | Panel Replay enabled | Sluggish |
| Same 7.2.4 session, debug 64 | PSR1 enabled, Panel Replay disabled | Smooth again |

The 7.2.3 live comparison held the kernel, applications and power profile constant; custom shell plugins were disabled and LibrePods stopped. Restoring plugins and Balanced mode with the workaround retained smoothness. Those plugins are not required to trigger this symptom.

The existing `xe.enable_psr2_sel_fetch=0` setting was retained throughout these comparisons. The 7.2.4 test explicitly omitted the persistent Panel Replay disable option. Its signed manifest and both package checksums were verified; this was `linux-omarchy` base, not BORE/MuQSS/T2, from source revision `c584bb66097936f689ad0a4808c88f9a8f3a29f7`.

#### Reproduction on this machine

1. Boot either affected kernel with the existing selective-fetch setting above, without `xe.enable_panel_replay=0`.
2. Confirm Panel Replay is active in `/sys/kernel/debug/dri/0/i915_edp_psr_status`.
3. Move the pointer, change workspaces and observe terminal rendering: motion feels sluggish.
4. Disable only Panel Replay and inspect the resulting mode:

```sh
echo 64 | sudo tee /sys/kernel/debug/dri/0/i915_edp_psr_debug
sudo cat /sys/kernel/debug/dri/0/i915_edp_psr_status
```

The driver reports `PSR1 enabled`, and motion becomes smooth. On 7.2.3, writing `0` back reproduced the lag immediately. These are direct observations of the physical display, not measured FPS benchmarks.

#### Logs and workaround

All three tested kernel versions logged:

```text
Applying Panel Replay ALPM cursor lag workaround
```

The original affected 7.2.3 boot had 86 PSR timeout messages, predominantly:

```text
Timed out waiting for PSR Idle for re-enable
```

The old-kernel captures had none. However, the later live comparison reproduced lag without new timeout messages, so those errors are supporting evidence rather than a required symptom.

The verified persistent workaround on normal 7.2.3 PTL is `/etc/limine-entry-tool.d/xe-panel-replay-workaround.conf` containing:

```sh
KERNEL_CMDLINE[default]+=" xe.enable_panel_replay=0"
```

Rebuild with `limine-mkinitcpio linux-ptl` and reboot. The runtime parameter was verified as 0, debug override remained 0, and the driver reported PSR1 enabled. No daemon is needed. Battery impact has not been measured.

Full completed-test report: https://mdpad.live/d/xoVGZvOVfMaXw0W1nCI6e

Related reports: #6853 (XPS 13 / Wildcat Lake), #6768 (earlier XPS 16 / Panther Lake issue). This report adds an XPS 14 kernel-only comparison and reproduction on the maintainer-provided 7.2.4 base build; I have not established that their exact underlying cause is identical.

The tests establish a Panel Replay-dependent regression on this machine and a working workaround. **The exact offending commit has not been identified.**

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 11:21 UTC