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.
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
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
System details
- Dell XPS 14 DA14260; Intel Core Ultra X7 358H; 32 GB RAM.
- Intel Panther Lake Arc B390 (
8086:b080),xedriver. - 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, Hyprland0.56.2-2, Mesa1:26.2.2-1. - Last tested good with Panel Replay enabled:
7.1.8-arch1-2-ptl. - Affected:
7.2.3-arch1-1-ptland maintainer-provided base7.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
- Boot either affected kernel with the existing selective-fetch setting above, without
xe.enable_panel_replay=0. - Confirm Panel Replay is active in
/sys/kernel/debug/dri/0/i915_edp_psr_status. - Move the pointer, change workspaces and observe terminal rendering: motion feels sluggish.
- 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_statusThe 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 workaroundThe original affected 7.2.3 boot had 86 PSR timeout messages, predominantly:
Timed out waiting for PSR Idle for re-enableThe 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