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.
Jittery scrolling on Dell XPS 13 (Wildcat Lake): Panel Replay stalls frame delivery
Reported by zoan37 · filed Aug 14, 2026Closed upstream on 2026-10-07 by spencerbull. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not evidence of a fix.
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
System details
Dell XPS 13 DX13260 (Intel Core 5 320 / Wildcat Lake Xe3 iGPU), 2560x1600@120Hz IPS eDP panel, Omarchy 4.0.0rc4, stock Arch kernel 7.1.8-arch1
What's wrong?
Out of the box, scrolling and animation judder visibly — motion looks like it runs far below the panel's 120Hz (mainly observed while scrolling in Google Chrome on x.com and other sites, but it's panel-level, not app-level). Frame-time instrumentation shows frames being skipped in bursts, always in exact multiples of the 8.33ms refresh period (effective ~70–80fps on a 120Hz panel).
Root cause (validated): the eDP panel negotiates Panel Replay Selective Update (Early Transport) by default, and its sleep/wake path stalls frame delivery — /sys/kernel/debug/dri/0000:00:02.0/eDP-1/i915_psr_status shows the source sitting in SLEEP with Panel Replay SU active:
PSR mode: Panel Replay Selective Update enabled (Early Transport)
Source PSR/PanelReplay status: SLEEP [0x30200001]
PSR2 selective fetch: enabledDisabling it at runtime makes scrolling smooth instantly, isolating the panel as the cause:
echo 1 | sudo tee /sys/kernel/debug/dri/0000:00:02.0/i915_edp_psr_debugThis is the same Xe3 self-refresh pathology as fix-asus-ptl-b9406-display.sh and the retired Panther Lake XPS fix (#5315). That fix was removed because linux-ptl kernel patches superseded it — but Wildcat Lake XPS machines run the stock Arch kernel, where the problem is alive, and the old PTL gate never matched this generation. Every Wildcat Lake XPS 13 running Omarchy should be affected.
Fix: #6849 applies xe.enable_psr=0 xe.enable_panel_replay=0 via /etc/limine-entry-tool.d/, gated on XPS + Wildcat Lake, mirroring the B9406 precedent. Both knobs are required (enable_psr=0 doesn't cover Panel Replay; disabling only Panel Replay falls back to PSR2 selective fetch, which stutters the same way). Tradeoff is ~0.5–1.5W idle draw until the panel's wake path is fixed in mainline, at which point the workaround can be retired the way #5315 was.
🤖 Generated with Claude Code
View raw text
### System details Dell XPS 13 DX13260 (Intel Core 5 320 / Wildcat Lake Xe3 iGPU), 2560x1600@120Hz IPS eDP panel, Omarchy 4.0.0rc4, stock Arch kernel 7.1.8-arch1 ### What's wrong? Out of the box, scrolling and animation judder visibly — motion looks like it runs far below the panel's 120Hz (mainly observed while scrolling in Google Chrome on x.com and other sites, but it's panel-level, not app-level). Frame-time instrumentation shows frames being skipped in bursts, always in exact multiples of the 8.33ms refresh period (effective ~70–80fps on a 120Hz panel). **Root cause (validated):** the eDP panel negotiates **Panel Replay Selective Update (Early Transport)** by default, and its sleep/wake path stalls frame delivery — `/sys/kernel/debug/dri/0000:00:02.0/eDP-1/i915_psr_status` shows the source sitting in `SLEEP` with Panel Replay SU active: ``` PSR mode: Panel Replay Selective Update enabled (Early Transport) Source PSR/PanelReplay status: SLEEP [0x30200001] PSR2 selective fetch: enabled ``` Disabling it at runtime makes scrolling smooth instantly, isolating the panel as the cause: ``` echo 1 | sudo tee /sys/kernel/debug/dri/0000:00:02.0/i915_edp_psr_debug ``` This is the same Xe3 self-refresh pathology as `fix-asus-ptl-b9406-display.sh` and the retired Panther Lake XPS fix (#5315). That fix was removed because linux-ptl kernel patches superseded it — but Wildcat Lake XPS machines run the stock Arch kernel, where the problem is alive, and the old PTL gate never matched this generation. Every Wildcat Lake XPS 13 running Omarchy should be affected. **Fix:** #6849 applies `xe.enable_psr=0 xe.enable_panel_replay=0` via `/etc/limine-entry-tool.d/`, gated on XPS + Wildcat Lake, mirroring the B9406 precedent. Both knobs are required (`enable_psr=0` doesn't cover Panel Replay; disabling only Panel Replay falls back to PSR2 selective fetch, which stutters the same way). Tradeoff is ~0.5–1.5W idle draw until the panel's wake path is fixed in mainline, at which point the workaround can be retired the way #5315 was. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
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.