Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-4437GitHub issuePublicReceived

linux-firmware-amdgpu 20260519 (DMUB 0x09004700) black-screens Strix Halo + 5K DSC display

Reported by melonamin · filed May 27, 2026Closed upstream on 2026-08-18 by its own reporter melonamin. GitHub close reason: completed. Closed by its own reporter — not by itself evidence of a fix.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

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

linux-firmware-amdgpu 20260519 (DMUB 0x09004700) black-screens Strix Halo + 5K DSC displayrevision 1 · captured 2026-10-04 11:56 UTC via poll

Summary

After omarchy update on 2026-05-27 my machine boots to a black screen. Hyprland starts fine, but the only display (Apple Studio Display, 5K over DSC) is left disabled by amdgpu — modeset never completes.

Bisected to `linux-firmware-amdgpu` `20260410-1` → `20260519-1`. The linux 7.0.3 → 7.0.9 and mesa 26.0.6 → 26.1.1 bumps in the same update are not the cause. Reverting only the firmware fixes it.

This is ultimately an upstream linux-firmware/AMD DMUB regression, not an Omarchy bug — filing as a heads-up since omarchy update delivers it and other Strix Halo users with high-res/DSC displays will likely hit it. Workaround below.

Hardware

  • AMD Ryzen AI Max "Strix Halo", Radeon 8060S Graphics (radeonsi, strix_halo)
  • GPU 0000:c2:00.0 [1002:1586], amdgpu, DCN 3.5, GC 11.5
  • Display: Apple Studio Display, 5120x2880@60 via DSC, tiled (tile group=1 tiles=2x1, 2560x2880 per tile)

Symptom

Boot to black screen. hyprctl monitors all shows the panel disabled: true, currentFormat: Invalid; no mode is settable. hyprctl configerrors is clean.

dmesg with the bad firmware (20260519, DMUB version=0x09004700):

amdgpu [drm] Loading DMUB firmware via PSP: version=0x09004700
amdgpu [drm] Cannot find any crtc or sizes
[drm:dcn20_wait_for_blank_complete [amdgpu]] *ERROR* DC: failed to blank crtc!
amdgpu [drm] REG_WAIT timeout 1us * 100000 tries - optc35_disable_crtc line:162
amdgpu [drm] REG_WAIT timeout 1us * 100000 tries - optc35_disable_crtc line:165

With the good firmware (20260410, DMUB version=0x09004100) the display comes up at 5K. Note: those optc35_disable_crtc / failed to blank crtc lines also appear once at early boot in the working config, so they aren't the discriminator — the DMUB version and the final disabled state are.

Bisection

linuxlinux-firmware-amdgpuDMUBresult
7.0.3202604100x09004100works
7.0.9202605190x09004700black
7.0.3202605190x09004700black

mesa 26.1.1 is constant across all rows. Only the firmware changes the outcome. Likely blob: amdgpu/dcn_3_5_dmcub.bin.

Workaround

sudo pacman -U /var/cache/pacman/pkg/linux-firmware-amdgpu-20260410-1-any.pkg.tar.zst
sudo limine-mkinitcpio   # required: HOOKS=(... kms ...) bundles the GPU firmware into the UKI
sudo reboot

The UKI rebuild is required — with early KMS the firmware is embedded in /boot/EFI/Linux/*.efi, so downgrading the package alone leaves the bad blob in the boot image.

Booting a limine btrfs snapshot (which carries the old firmware) is a clean instant recovery — the snapshot setup worked well here.

Upstream

The real fix belongs in linux-firmware / AMD DMUB for DCN 3.5: https://gitlab.freedesktop.org/drm/amd/-/issues. Possible Omarchy-side mitigation: document it, or temporarily hold linux-firmware-amdgpu for Strix Halo until the firmware is fixed.

View raw text
## Summary

After `omarchy update` on 2026-05-27 my machine boots to a black screen. Hyprland starts fine, but the only display (Apple Studio Display, 5K over DSC) is left disabled by `amdgpu` — modeset never completes.

Bisected to **`linux-firmware-amdgpu` `20260410-1` → `20260519-1`**. The `linux` 7.0.3 → 7.0.9 and `mesa` 26.0.6 → 26.1.1 bumps in the same update are **not** the cause. Reverting only the firmware fixes it.

This is ultimately an upstream `linux-firmware`/AMD DMUB regression, not an Omarchy bug — filing as a heads-up since `omarchy update` delivers it and other Strix Halo users with high-res/DSC displays will likely hit it. Workaround below.

## Hardware

- AMD Ryzen AI Max "Strix Halo", Radeon 8060S Graphics (`radeonsi`, `strix_halo`)
- GPU `0000:c2:00.0` `[1002:1586]`, `amdgpu`, DCN 3.5, GC 11.5
- Display: Apple Studio Display, `5120x2880@60` via DSC, tiled (`tile group=1 tiles=2x1`, 2560x2880 per tile)

## Symptom

Boot to black screen. `hyprctl monitors all` shows the panel `disabled: true`, `currentFormat: Invalid`; no mode is settable. `hyprctl configerrors` is clean.

`dmesg` with the **bad** firmware (`20260519`, DMUB `version=0x09004700`):

```
amdgpu [drm] Loading DMUB firmware via PSP: version=0x09004700
amdgpu [drm] Cannot find any crtc or sizes
[drm:dcn20_wait_for_blank_complete [amdgpu]] *ERROR* DC: failed to blank crtc!
amdgpu [drm] REG_WAIT timeout 1us * 100000 tries - optc35_disable_crtc line:162
amdgpu [drm] REG_WAIT timeout 1us * 100000 tries - optc35_disable_crtc line:165
```

With the **good** firmware (`20260410`, DMUB `version=0x09004100`) the display comes up at 5K. Note: those `optc35_disable_crtc` / `failed to blank crtc` lines also appear once at early boot in the *working* config, so they aren't the discriminator — the DMUB version and the final disabled state are.

## Bisection

| `linux` | `linux-firmware-amdgpu` | DMUB | result |
|---|---|---|---|
| 7.0.3 | 20260410 | 0x09004100 | works |
| 7.0.9 | 20260519 | 0x09004700 | black |
| 7.0.3 | 20260519 | 0x09004700 | black |

`mesa` 26.1.1 is constant across all rows. Only the firmware changes the outcome. Likely blob: `amdgpu/dcn_3_5_dmcub.bin`.

## Workaround

```bash
sudo pacman -U /var/cache/pacman/pkg/linux-firmware-amdgpu-20260410-1-any.pkg.tar.zst
sudo limine-mkinitcpio   # required: HOOKS=(... kms ...) bundles the GPU firmware into the UKI
sudo reboot
```

The UKI rebuild is required — with early KMS the firmware is embedded in `/boot/EFI/Linux/*.efi`, so downgrading the package alone leaves the bad blob in the boot image.

Booting a limine btrfs snapshot (which carries the old firmware) is a clean instant recovery — the snapshot setup worked well here.

## Upstream

The real fix belongs in `linux-firmware` / AMD DMUB for DCN 3.5: https://gitlab.freedesktop.org/drm/amd/-/issues. Possible Omarchy-side mitigation: document it, or temporarily hold `linux-firmware-amdgpu` for Strix Halo until the firmware is fixed.

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.