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.
linux-omarchy 7.2.5 (xe, Panther Lake): USB4 monitor's EDID read fails on about half of hotplugs, display stuck at 640x480
Reported by diazkev314 · filed Sep 17, 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 16 DA16260, Core Ultra X7 358H / Arc B390 (xe), Omarchy 4.0.4-1, linux-omarchy 7.2.5-3, Hyprland 0.56.2, Samsung S27C900P (USB4), CalDigit TS5 or direct
What's wrong?
When I plug my Samsung ViewFinity S9 (S27C900P, a USB4 monitor) into my XPS 16, about half the time it comes up at 640x480 with everything huge. hyprctl monitors shows DP-1 at 640x480 with an empty description, so my desc: monitor rule never matches. The kernel logs EDID has corrupt header, /sys/class/drm/card0-DP-1/edid is empty, and modes only lists the fallback resolutions. hyprctl reload doesn't help, and the modeless recovery in omarchy-hyprland-monitor-watch doesn't catch it either, since the monitor does have a mode, just the wrong one. It happens with and without my CalDigit TS5 dock, and it never happens on macOS with the same monitor. I updated the BIOS to 1.8.2 today; still happens.
I captured a failing plug-in with drm.debug=0x104 (attached). What the log shows: the kernel reads the EDID once, about 0.2 s after hotplug, while the monitor is still answering with I2C defers (64 of them in 170 ms). The data that comes back isn't garbage: it's bytes 256 to 383 of the monitor's real EDID (E-DDC segment 1), so the header check fails. The kernel retries four times inside that same 170 ms window and then never again, so the fallback modes stay until something re-probes the connector.
18:33:59.296 [CONNECTOR:521:DP-1] status updated from disconnected to connected
18:33:59.523 drm_dp_i2c_do_msg ... I2C defer (x64), native defer (x12)
18:33:59.695 EDID has corrupt header
[00] BAD 70 12 79 00 00 01 00 0c 52 17 20 0d 00 14 40 0b <- these are bytes 256..271 of the real EDIDIf I re-probe a few seconds later (echo off then echo detect into /sys/class/drm/card0-DP-1/status), the full 512-byte EDID comes back every time (8 of 8 today). Reading the DDC by hand 5 s after a failed plug-in also returns the correct data (i2ctransfer -y 12 w1@0x50 0x00 r16@0x50 gives 00 ff ff ff ff ff ff 00 4c 2d ...). So the monitor misbehaves during its first second, and the kernel only gives it one chance inside that second.
As a workaround I'm running a udev rule on DRM change events that starts a small script via systemd-run: if an external connector is connected but its edid is empty, it does the off/detect cycle (3 s settle, up to 3 tries, then stops until the monitor is unplugged). A system-sleep hook covers the after-resume case, where the kernel re-reads the EDID on its own but Hyprland keeps driving 640x480. Every failure so far has recovered, most on the first try. Happy to share it if it's useful to ship, and happy to test a patched linux-omarchy.
Debug log: https://logs.omarchy.org/BR7gLB
Small side note: the Omarchy agent skill shipped in /usr/share/omarchy/default/agents/skills/omarchy/ (SKILL.md and contributing.md) tells the agent to run omarchy debug, which doesn't exist in 4.0.4; the command is omarchy-debug.
View raw text
### System details
Dell XPS 16 DA16260, Core Ultra X7 358H / Arc B390 (xe), Omarchy 4.0.4-1, linux-omarchy 7.2.5-3, Hyprland 0.56.2, Samsung S27C900P (USB4), CalDigit TS5 or direct
### What's wrong?
When I plug my Samsung ViewFinity S9 (S27C900P, a USB4 monitor) into my XPS 16, about half the time it comes up at 640x480 with everything huge. `hyprctl monitors` shows DP-1 at 640x480 with an empty description, so my `desc:` monitor rule never matches. The kernel logs `EDID has corrupt header`, `/sys/class/drm/card0-DP-1/edid` is empty, and `modes` only lists the fallback resolutions. `hyprctl reload` doesn't help, and the modeless recovery in `omarchy-hyprland-monitor-watch` doesn't catch it either, since the monitor does have a mode, just the wrong one. It happens with and without my CalDigit TS5 dock, and it never happens on macOS with the same monitor. I updated the BIOS to 1.8.2 today; still happens.
I captured a failing plug-in with `drm.debug=0x104` (attached). What the log shows: the kernel reads the EDID once, about 0.2 s after hotplug, while the monitor is still answering with I2C defers (64 of them in 170 ms). The data that comes back isn't garbage: it's bytes 256 to 383 of the monitor's real EDID (E-DDC segment 1), so the header check fails. The kernel retries four times inside that same 170 ms window and then never again, so the fallback modes stay until something re-probes the connector.
```
18:33:59.296 [CONNECTOR:521:DP-1] status updated from disconnected to connected
18:33:59.523 drm_dp_i2c_do_msg ... I2C defer (x64), native defer (x12)
18:33:59.695 EDID has corrupt header
[00] BAD 70 12 79 00 00 01 00 0c 52 17 20 0d 00 14 40 0b <- these are bytes 256..271 of the real EDID
```
If I re-probe a few seconds later (`echo off` then `echo detect` into `/sys/class/drm/card0-DP-1/status`), the full 512-byte EDID comes back every time (8 of 8 today). Reading the DDC by hand 5 s after a failed plug-in also returns the correct data (`i2ctransfer -y 12 w1@0x50 0x00 r16@0x50` gives `00 ff ff ff ff ff ff 00 4c 2d ...`). So the monitor misbehaves during its first second, and the kernel only gives it one chance inside that second.
As a workaround I'm running a udev rule on DRM change events that starts a small script via `systemd-run`: if an external connector is `connected` but its `edid` is empty, it does the off/detect cycle (3 s settle, up to 3 tries, then stops until the monitor is unplugged). A system-sleep hook covers the after-resume case, where the kernel re-reads the EDID on its own but Hyprland keeps driving 640x480. Every failure so far has recovered, most on the first try. Happy to share it if it's useful to ship, and happy to test a patched linux-omarchy.
Debug log: https://logs.omarchy.org/BR7gLB
Small side note: the Omarchy agent skill shipped in `/usr/share/omarchy/default/agents/skills/omarchy/` (SKILL.md and contributing.md) tells the agent to run `omarchy debug`, which doesn't exist in 4.0.4; the command is `omarchy-debug`.
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 14:38 UTC