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-4974GitHub issuePublicFixed

omarchy-hyprland-monitor-external-active counts Hyprland's FALLBACK output → laptop panel stuck off after undock-by-unplug

Reported by qtn10 · filed Sep 9, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #10584 (R-882). GitHub close reason: completed.

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

omarchy-hyprland-monitor-external-active counts Hyprland's FALLBACK output → laptop panel stuck off after undock-by-unplugrevision 1 · captured 2026-10-04 12:10 UTC via poll

What happened

omarchy-hyprland-monitor-external-active returns true when the only
non-internal output Hyprland reports is its own FALLBACK placeholder (the
headless output Hyprland spawns when there are no usable real outputs).

Because omarchy-hyprland-monitor-internal recover() and
omarchy-hyprland-monitor-clamshell enable_internal() both early-return on
that check, disabling the laptop panel while docked and then unplugging the
external monitor leaves the laptop panel disabled forever — a black screen until
the external is reconnected.

Steps to reproduce

  1. Connect an external monitor.
  2. omarchy-hyprland-monitor-internal off (same path as SUPER + CTRL + Delete

→ "Toggle laptop display"). Laptop panel goes dark; internal-monitor-disable.lua
toggle flag is written.
3. Physically unplug the external monitor's cable.

Expected: laptop panel comes back on (recover() clears the flag + reloads).

Actual: laptop panel stays disabled indefinitely; both screens off.

Evidence

2s samples for 30s after step 3, with no third-party scripts running:

HDMI=disconnected  mons=[eDP-1,FALLBACK]  eDP.disabled=true  ext-active=YES  flag+
HDMI=disconnected  mons=[eDP-1,FALLBACK]  eDP.disabled=true  ext-active=YES  flag+
   ... identical for the full 30s ...

ext-active=YES is the exit status of omarchy-hyprland-monitor-external-active.

Root cause

omarchy-hyprland-monitor-external-active:

hyprctl monitors all -j | jq -e '.[]
  | select(.name | test("^(eDP|LVDS|DSI)-") | not)
  | select(.disabled == false)' >/dev/null 2>&1

FALLBACK is not eDP-* / LVDS-* / DSI-* and is disabled == false, so the
filter matches it and the function reports an external monitor is present.

recover() runs from the monitor watcher on every monitorremoved, so this is
reliably hit, not a race.

Suggested fix

Exclude Hyprland's placeholder outputs:

hyprctl monitors all -j | jq -e '.[]
  | select(.name | test("^(eDP|LVDS|DSI)-|^FALLBACK$|^HEADLESS-"; "i") | not)
  | select(.disabled == false)' >/dev/null 2>&1

Environment

Omarchy4.0.2-1
Hyprland0.56.2 (efb5099)
HardwareASUS ROG Flow X13 GV302XA — Ryzen 9 7940HS / Radeon 780M
Kernel7.1.9-arch1-2
Internal / externaleDP-1 / HDMI-A-1 (MSI G321Q)
View raw text
## What happened

`omarchy-hyprland-monitor-external-active` returns **true** when the only
non-internal output Hyprland reports is its own `FALLBACK` placeholder (the
headless output Hyprland spawns when there are no usable real outputs).

Because `omarchy-hyprland-monitor-internal` `recover()` and
`omarchy-hyprland-monitor-clamshell` `enable_internal()` both early-return on
that check, disabling the laptop panel while docked and then **unplugging** the
external monitor leaves the laptop panel disabled forever — a black screen until
the external is reconnected.

## Steps to reproduce

1. Connect an external monitor.
2. `omarchy-hyprland-monitor-internal off` (same path as `SUPER + CTRL + Delete`
   → "Toggle laptop display"). Laptop panel goes dark; `internal-monitor-disable.lua`
   toggle flag is written.
3. Physically **unplug** the external monitor's cable.

**Expected:** laptop panel comes back on (`recover()` clears the flag + reloads).

**Actual:** laptop panel stays disabled indefinitely; both screens off.

## Evidence

2s samples for 30s after step 3, with no third-party scripts running:

```
HDMI=disconnected  mons=[eDP-1,FALLBACK]  eDP.disabled=true  ext-active=YES  flag+
HDMI=disconnected  mons=[eDP-1,FALLBACK]  eDP.disabled=true  ext-active=YES  flag+
   ... identical for the full 30s ...
```

`ext-active=YES` is the exit status of `omarchy-hyprland-monitor-external-active`.

## Root cause

`omarchy-hyprland-monitor-external-active`:

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

`FALLBACK` is not `eDP-*` / `LVDS-*` / `DSI-*` and is `disabled == false`, so the
filter matches it and the function reports an external monitor is present.

`recover()` runs from the monitor watcher on every `monitorremoved`, so this is
reliably hit, not a race.

## Suggested fix

Exclude Hyprland's placeholder outputs:

```bash
hyprctl monitors all -j | jq -e '.[]
  | select(.name | test("^(eDP|LVDS|DSI)-|^FALLBACK$|^HEADLESS-"; "i") | not)
  | select(.disabled == false)' >/dev/null 2>&1
```

## Environment

| | |
|---|---|
| Omarchy | 4.0.2-1 |
| Hyprland | 0.56.2 (`efb5099`) |
| Hardware | ASUS ROG Flow X13 GV302XA — Ryzen 9 7940HS / Radeon 780M |
| Kernel | 7.1.9-arch1-2 |
| Internal / external | `eDP-1` / `HDMI-A-1` (MSI G321Q) |

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

  • Fixed bypr/7146· confirmed

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.