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-2136GitHub issuePublicDecided· Out of scope

External monitors stay at 0x0 after resume from a USB-C dock

Reported by CoreSaint · filed Sep 30, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 3 days ago.

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

External monitors stay at 0x0 after resume from a USB-C dockrevision 1 · captured 2026-09-30 22:11 UTC via poll

System details

Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy, Hyprland 0.56.2, AMD Krackan [Radeon 840M / 860M] [1002:1114]. Internal panel: LG Display eDP 1920x1200. External panels: Acer X34 GS over DisplayPort, and two Samsung LU28R55 panels through a UGREEN CM639 USB-C dock.

What's wrong?

Multi-monitor use on this Omarchy system is currently unreliable enough to make the machine unusable as a docked workstation. I have not had this many external-monitor failures on any other Linux system.

What happens:

  1. Boot on the UGREEN CM639 dock with two Samsung LU28R55 HDMI displays. The kernel log shows DisplayPort MST and DSC setup.
  2. Suspend the laptop.
  3. Resume later on the Acer X34 GS connected directly by DisplayPort, with the dock disconnected.
  4. The Acer is detected, including its EDID and mode list, but its active mode stays 0x0. The internal panel keeps working.
  5. Hyprland/Aquamarine then rejects every modeset, including modes that previously worked (3440x1440@60 and 1920x1080@60), with atomic drm request: failed to commit: Invalid argument.
  6. Immediately after resume, amdgpu reports:
amdgpu 0000:c4:00.0: [drm] *ERROR* dpcd_set_link_settings:1123: core_link_write_dpcd (DP_DOWNSPREAD_CTRL) failed
amdgpu 0000:c4:00.0: [drm] *ERROR* dpcd_set_link_settings:1128: core_link_write_dpcd (DP_LANE_COUNT_SET) failed
amdgpu 0000:c4:00.0: [drm] *ERROR* dpcd_set_link_settings:1156: core_link_write_dpcd (DP_LINK_BW_SET) failed
  1. The DRM connector remains status=connected, enabled=disabled, dpms=Off. Hyprland still lists the monitor as present and not disabled, so other programs log gdk_monitor_set_scale: assertion 'scale > 0.' failed.

The same 0x0 failure also happened earlier the same day on the dock: both Samsungs were detected, neither could be modeset, and connecting the second display blanked the first. A reboot temporarily restored output. This is not a one-time cable reseat; it follows suspend/resume and dock changes.

Expected: after resume, an external display with a valid EDID is programmed at a supported mode and remains usable.

The Acer's preferred mode is 3440x1440@180. That mode has also failed atomic commit on this machine, so a preferred-mode fallback is not safe here.

View raw text
### System details

Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy, Hyprland 0.56.2, AMD Krackan [Radeon 840M / 860M] [1002:1114]. Internal panel: LG Display eDP 1920x1200. External panels: Acer X34 GS over DisplayPort, and two Samsung LU28R55 panels through a UGREEN CM639 USB-C dock.

### What's wrong?

Multi-monitor use on this Omarchy system is currently unreliable enough to make the machine unusable as a docked workstation. I have not had this many external-monitor failures on any other Linux system.

What happens:

1. Boot on the UGREEN CM639 dock with two Samsung LU28R55 HDMI displays. The kernel log shows DisplayPort MST and DSC setup.
2. Suspend the laptop.
3. Resume later on the Acer X34 GS connected directly by DisplayPort, with the dock disconnected.
4. The Acer is detected, including its EDID and mode list, but its active mode stays 0x0. The internal panel keeps working.
5. Hyprland/Aquamarine then rejects every modeset, including modes that previously worked (3440x1440@60 and 1920x1080@60), with `atomic drm request: failed to commit: Invalid argument`.
6. Immediately after resume, amdgpu reports:

```
amdgpu 0000:c4:00.0: [drm] *ERROR* dpcd_set_link_settings:1123: core_link_write_dpcd (DP_DOWNSPREAD_CTRL) failed
amdgpu 0000:c4:00.0: [drm] *ERROR* dpcd_set_link_settings:1128: core_link_write_dpcd (DP_LANE_COUNT_SET) failed
amdgpu 0000:c4:00.0: [drm] *ERROR* dpcd_set_link_settings:1156: core_link_write_dpcd (DP_LINK_BW_SET) failed
```

7. The DRM connector remains `status=connected`, `enabled=disabled`, `dpms=Off`. Hyprland still lists the monitor as present and not disabled, so other programs log `gdk_monitor_set_scale: assertion 'scale > 0.' failed`.

The same 0x0 failure also happened earlier the same day on the dock: both Samsungs were detected, neither could be modeset, and connecting the second display blanked the first. A reboot temporarily restored output. This is not a one-time cable reseat; it follows suspend/resume and dock changes.

Expected: after resume, an external display with a valid EDID is programmed at a supported mode and remains usable.

The Acer's preferred mode is 3440x1440@180. That mode has also failed atomic commit on this machine, so a preferred-mode fallback is not safe here.

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 20:24 UTC