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: HDMI FRL link training fails on RX 9070 XT, no signal at 4K120
Reported by itmmdj · filed Sep 25, 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
Summary
Since migration 1789325478 installed linux-omarchy and made it the first Limine entry, my 4K TV shows "no signal" at 3840x2160@120 over HDMI on most boots. The kernel logs amdgpu 0000:03:00.0: [drm] enabling link 3 failed: 19 every time. The stock Arch linux kernel 7.2.3 on the same machine, cable, TV and config trains the link every time.
System
- Omarchy 4.0.4-1
- CPU: AMD Ryzen 5 9600X
- GPU: AMD Radeon RX 9070 XT (Navi 48,
1002:7550), DCN 4.0.1, DMUB firmware0x0A000C00 - Display: Samsung 4K TV on HDMI-A-1, directly connected to the 9070 XT
linux-omarchy7.2.5-3 (failing),linux7.2.3.arch1-3 (working)linux-firmware-amdgpu20260810-2,mesa26.2.2-1,hyprland0.56.2-2
Steps to reproduce
- Set the TV to 3840x2160@120 in
~/.config/hypr/monitors.lua. - Boot
linux-omarchy7.2.5-3. - The TV shows no signal.
journalctl -k -b | grep 'enabling link 3 failed'shows the error.
Switching modes at runtime gives the same result on linux-omarchy:
| Mode | Needs FRL | Result |
|---|---|---|
| 3840x2160@120 | yes | no signal, link failure logged |
| 3840x2160@100 | yes | no signal, link failure logged |
| 3840x2160@60 | no | works |
| 2560x1440@120 | no | works |
Booting stock linux 7.2.3 from the Limine menu with the same config brings up 3840x2160@120 with no link failures.
Evidence
Count of enabling link 3 failed per boot, from the journal:
| Kernel | Boots | Boots with the failure |
|---|---|---|
| 7.1.8-arch1-3 | 10 | 0 |
| 7.1.9-arch1-2 | 17 | 0 |
| 7.2.3-arch1-3 | 10, plus 2 today | 0 |
| 7.2.5-3-omarchy | 13 | 9 |
The first failure is on the first boot after the migration switched Limine to linux-omarchy (2026-09-18). On one 7.2.5 boot the TV also fell back to a basic EDID with no HDMI Forum block and a 300 MHz max dotclock. The next boot got the full EDID back.
The AMD and DRM kernel config options match between the two kernels, apart from debug options that are off in both and options new in 7.2.5. So the difference is in the kernel source.
Open question
I haven't tested stock Arch linux 7.2.5, so I can't tell whether this comes from an upstream 7.2.3 to 7.2.5 change or from a linux-omarchy patch. If linux-omarchy carries amdgpu or DRM patches, those are the first place to look.
Workaround
Put stock linux first in BOOT_ORDER in /etc/default/limine, then run sudo limine-update.
View raw text
## Summary Since migration 1789325478 installed `linux-omarchy` and made it the first Limine entry, my 4K TV shows "no signal" at 3840x2160@120 over HDMI on most boots. The kernel logs `amdgpu 0000:03:00.0: [drm] enabling link 3 failed: 19` every time. The stock Arch `linux` kernel 7.2.3 on the same machine, cable, TV and config trains the link every time. ## System - Omarchy 4.0.4-1 - CPU: AMD Ryzen 5 9600X - GPU: AMD Radeon RX 9070 XT (Navi 48, `1002:7550`), DCN 4.0.1, DMUB firmware `0x0A000C00` - Display: Samsung 4K TV on HDMI-A-1, directly connected to the 9070 XT - `linux-omarchy` 7.2.5-3 (failing), `linux` 7.2.3.arch1-3 (working) - `linux-firmware-amdgpu` 20260810-2, `mesa` 26.2.2-1, `hyprland` 0.56.2-2 ## Steps to reproduce 1. Set the TV to 3840x2160@120 in `~/.config/hypr/monitors.lua`. 2. Boot `linux-omarchy` 7.2.5-3. 3. The TV shows no signal. `journalctl -k -b | grep 'enabling link 3 failed'` shows the error. Switching modes at runtime gives the same result on `linux-omarchy`: | Mode | Needs FRL | Result | |---|---|---| | 3840x2160@120 | yes | no signal, link failure logged | | 3840x2160@100 | yes | no signal, link failure logged | | 3840x2160@60 | no | works | | 2560x1440@120 | no | works | Booting stock `linux` 7.2.3 from the Limine menu with the same config brings up 3840x2160@120 with no link failures. ## Evidence Count of `enabling link 3 failed` per boot, from the journal: | Kernel | Boots | Boots with the failure | |---|---|---| | 7.1.8-arch1-3 | 10 | 0 | | 7.1.9-arch1-2 | 17 | 0 | | 7.2.3-arch1-3 | 10, plus 2 today | 0 | | 7.2.5-3-omarchy | 13 | 9 | The first failure is on the first boot after the migration switched Limine to `linux-omarchy` (2026-09-18). On one 7.2.5 boot the TV also fell back to a basic EDID with no HDMI Forum block and a 300 MHz max dotclock. The next boot got the full EDID back. The AMD and DRM kernel config options match between the two kernels, apart from debug options that are off in both and options new in 7.2.5. So the difference is in the kernel source. ## Open question I haven't tested stock Arch `linux` 7.2.5, so I can't tell whether this comes from an upstream 7.2.3 to 7.2.5 change or from a `linux-omarchy` patch. If `linux-omarchy` carries amdgpu or DRM patches, those are the first place to look. ## Workaround Put stock `linux` first in `BOOT_ORDER` in `/etc/default/limine`, then run `sudo limine-update`.
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 18:21 UTC