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.
[Bug]: Intel Arc (xe driver) fails to wake up 240Hz DSC DisplayPort monitors after DPMS / sleep idle
Reported by ozdil · filed Sep 5, 2026 · open at source
This defect is tracked under R-323. This report describes the same defect, so it is folded under it in the inbox.
Earliest report of this defect: R-921 (filed Sep 5, 2026).
Decided by agents · verified· Oct 9, 2026
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?
- 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
Describe the bug
When using an Intel Arc GPU (Battlemage B580) with the xe kernel driver and a high-bandwidth DisplayPort monitor (Samsung Odyssey OLED G9 49" 5120x1440 @ 240Hz with DSC), the monitor fails to wake up from DPMS / lock screen standby.
Moving the mouse or pressing keys triggers the session unlock, but the display remains completely black (monitor power LED blinks / remains in standby). The system requires a physical monitor power cycle or machine reboot to restore the DisplayPort output.
System Environment
- OS: Omarchy 4.0.2-1 (Arch Linux rolling)
- Kernel: Linux 7.1.9-arch1-2
- Compositor: Hyprland 0.56 (Wayland) / Omarchy Quickshell
- GPU: Intel Arc B580 12GB (Battlemage G21)
- Driver:
xekernel module - Display: Samsung Odyssey OLED G9 (G93SC) 49" 32:9 (5120x1440 @ 240Hz via DisplayPort 1.4 + DSC)
Root Cause Analysis
- When Omarchy's idle timer reaches lock timeout, it invokes DPMS disable (
hl.dsp.dpms({ action = "disable" })). - The Intel
xekernel driver aggressively gates display power wells and enters DC5/DC6 (Display C-States). - Upon wakeup input, the
xedriver attempts link training. Because the display PLL and transmitter PHY are recovering from DC6 sleep state, link training times out on 240Hz DSC timings before the monitor TCON responds. - The DRM subsystem fails modeset / atomic update, leaving the connector stalled.
Logs / Symptoms
[drm] DisplayID checksum invalid, remainder is 144
xe 0000:03:00.0: [drm] *ERROR* Atomic update failure on pipe BVerified Workaround & Solution
Creating /etc/modprobe.d/intel-arc-sleep-fix.conf with:
options xe enable_dc=0 enable_psr=0 disable_power_well=0and updating initramfs (mkinitcpio -P) completely resolves the issue. DisplayPort wakeups become instant without link training timeouts.
Proposed Fix for Omarchy
Consider adding a default modprobe quirk for Intel xe graphics (similar to omarchy-usb-autosuspend.conf and blacklist-xpad.conf) or providing an automated hardware detection rule in Omarchy so Intel Arc discrete GPUs do not freeze high-refresh DSC displays after sleep.
View raw text
### Describe the bug
When using an Intel Arc GPU (Battlemage B580) with the `xe` kernel driver and a high-bandwidth DisplayPort monitor (Samsung Odyssey OLED G9 49" 5120x1440 @ 240Hz with DSC), the monitor fails to wake up from DPMS / lock screen standby.
Moving the mouse or pressing keys triggers the session unlock, but the display remains completely black (monitor power LED blinks / remains in standby). The system requires a physical monitor power cycle or machine reboot to restore the DisplayPort output.
### System Environment
- **OS:** Omarchy 4.0.2-1 (Arch Linux rolling)
- **Kernel:** Linux 7.1.9-arch1-2
- **Compositor:** Hyprland 0.56 (Wayland) / Omarchy Quickshell
- **GPU:** Intel Arc B580 12GB (Battlemage G21)
- **Driver:** `xe` kernel module
- **Display:** Samsung Odyssey OLED G9 (G93SC) 49" 32:9 (5120x1440 @ 240Hz via DisplayPort 1.4 + DSC)
### Root Cause Analysis
1. When Omarchy's idle timer reaches lock timeout, it invokes DPMS disable (`hl.dsp.dpms({ action = "disable" })`).
2. The Intel `xe` kernel driver aggressively gates display power wells and enters **DC5/DC6 (Display C-States)**.
3. Upon wakeup input, the `xe` driver attempts link training. Because the display PLL and transmitter PHY are recovering from DC6 sleep state, link training times out on 240Hz DSC timings before the monitor TCON responds.
4. The DRM subsystem fails modeset / atomic update, leaving the connector stalled.
### Logs / Symptoms
```text
[drm] DisplayID checksum invalid, remainder is 144
xe 0000:03:00.0: [drm] *ERROR* Atomic update failure on pipe B
```
### Verified Workaround & Solution
Creating `/etc/modprobe.d/intel-arc-sleep-fix.conf` with:
```ini
options xe enable_dc=0 enable_psr=0 disable_power_well=0
```
and updating initramfs (`mkinitcpio -P`) completely resolves the issue. DisplayPort wakeups become instant without link training timeouts.
### Proposed Fix for Omarchy
Consider adding a default modprobe quirk for Intel `xe` graphics (similar to `omarchy-usb-autosuspend.conf` and `blacklist-xpad.conf`) or providing an automated hardware detection rule in Omarchy so Intel Arc discrete GPUs do not freeze high-refresh DSC displays after sleep.
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
- Duplicate ofR-323Don't DPMS-off Apple Studio Display on lock — USB4 tunnel dies until power cycle· decided by agents · verified
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.