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-5379GitHub issuePublicReceived

Laptop display stays disabled after unplugging external monitor: FALLBACK output counted as external

Reported by Sambigeara · filed Oct 13, 2026 · open at source

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

Laptop display stays disabled after unplugging external monitor: FALLBACK output counted as externalrevision 1 · captured 2026-10-13 08:16 UTC via poll

System details

  • Omarchy 4.0.4-1
  • Hyprland 0.56.2-2, aquamarine 0.15.0-2
  • Kernel 7.2.5-3-omarchy
  • AMD Ryzen AI 9 HX 370 w/ Radeon 890M (amdgpu), mini laptop with a 1920x1080@120 internal panel (eDP-1)
  • External: Dell U2720Q over USB-C (DP-2)

What happened

  1. With the external monitor connected, disable the laptop display (omarchy hyprland monitor internal off).
  2. Unplug the external monitor.

Expected: the monitor watcher clears the internal-monitor-disable toggle and the laptop panel comes back.

Actual: the toggle stays set and the laptop panel stays off. The machine is left with no usable display.

Cause

With the only enabled output gone, Hyprland creates its placeholder output named FALLBACK. hyprctl monitors all at that point showed:

Monitor eDP-1 (ID 0):    ... disabled: true
Monitor FALLBACK (ID 1): [email protected] at 0x0 ... disabled: false, focused: yes

omarchy-hyprland-monitor-external-active treats any enabled output whose name is not eDP|LVDS|DSI as an external monitor:

hyprctl monitors all -j | jq -e '.[] | select(.name | test("^(eDP|LVDS|DSI)-") | not) | select(.disabled == false)'

FALLBACK matches, so the script returns true with nothing plugged in. omarchy-hyprland-monitor-internal recover then returns early on its first line (omarchy-hyprland-monitor-external-active && return 0) and never clears the toggle. ~/.local/state/omarchy/toggles/hypr/internal-monitor-disable.lua was still present well after the unplug, while omarchy hw external monitors (the sysfs check) correctly returned false.

Suggested fix

Exclude FALLBACK in omarchy-hyprland-monitor-external-active, for example test("^(eDP|LVDS|DSI)-|^FALLBACK$"), or have recover rely on the physical check in omarchy-hw-external-monitors.

Notes

  • Observed once; I have not re-run the repro, but the script logic above is deterministic given a FALLBACK output.
  • Running omarchy hyprland monitor internal on by hand cleared the toggle, but the panel still did not light on this machine: Hyprland's modesets were failing with atomic drm request: failed to commit: Invalid argument because the kernel still had the unplugged monitor's CRTC active. That part looks like a Hyprland/aquamarine problem rather than Omarchy's, and needed a VT switch plus hyprctl reload to clear. Mentioning it because fixing the detection alone may not fully recover in this situation.
  • I can supply omarchy debug output if useful.
View raw text
## System details

- Omarchy 4.0.4-1
- Hyprland 0.56.2-2, aquamarine 0.15.0-2
- Kernel 7.2.5-3-omarchy
- AMD Ryzen AI 9 HX 370 w/ Radeon 890M (amdgpu), mini laptop with a 1920x1080@120 internal panel (`eDP-1`)
- External: Dell U2720Q over USB-C (`DP-2`)

## What happened

1. With the external monitor connected, disable the laptop display (`omarchy hyprland monitor internal off`).
2. Unplug the external monitor.

Expected: the monitor watcher clears the `internal-monitor-disable` toggle and the laptop panel comes back.

Actual: the toggle stays set and the laptop panel stays off. The machine is left with no usable display.

## Cause

With the only enabled output gone, Hyprland creates its placeholder output named `FALLBACK`. `hyprctl monitors all` at that point showed:

```
Monitor eDP-1 (ID 0):    ... disabled: true
Monitor FALLBACK (ID 1): [email protected] at 0x0 ... disabled: false, focused: yes
```

`omarchy-hyprland-monitor-external-active` treats any enabled output whose name is not `eDP|LVDS|DSI` as an external monitor:

```bash
hyprctl monitors all -j | jq -e '.[] | select(.name | test("^(eDP|LVDS|DSI)-") | not) | select(.disabled == false)'
```

`FALLBACK` matches, so the script returns true with nothing plugged in. `omarchy-hyprland-monitor-internal recover` then returns early on its first line (`omarchy-hyprland-monitor-external-active && return 0`) and never clears the toggle. `~/.local/state/omarchy/toggles/hypr/internal-monitor-disable.lua` was still present well after the unplug, while `omarchy hw external monitors` (the sysfs check) correctly returned false.

## Suggested fix

Exclude `FALLBACK` in `omarchy-hyprland-monitor-external-active`, for example `test("^(eDP|LVDS|DSI)-|^FALLBACK$")`, or have `recover` rely on the physical check in `omarchy-hw-external-monitors`.

## Notes

- Observed once; I have not re-run the repro, but the script logic above is deterministic given a `FALLBACK` output.
- Running `omarchy hyprland monitor internal on` by hand cleared the toggle, but the panel still did not light on this machine: Hyprland's modesets were failing with `atomic drm request: failed to commit: Invalid argument` because the kernel still had the unplugged monitor's CRTC active. That part looks like a Hyprland/aquamarine problem rather than Omarchy's, and needed a VT switch plus `hyprctl reload` to clear. Mentioning it because fixing the detection alone may not fully recover in this situation.
- I can supply `omarchy debug` output if useful.

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.