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.
SDDM greeter's Hyprland config has no lid-switch/DPMS handling — external monitor won't wake after Log Out with lid closed
Reported by mehrdadkashefi · filed Sep 5, 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
What happened
On a laptop with the lid closed and an external monitor connected, the desktop
session correctly disables the internal panel and drives the external monitor
(clamshell mode). But after using "Log Out" (not Lock), moving the mouse or
pressing a key does not wake the external monitor. The only way to recover is
to physically open the lid and close it again.
Expected
Mouse/keyboard input at the SDDM login screen should wake the external
monitor, the same way it does inside a normal Hyprland session with the lid
closed.
Root cause (found by inspecting the shipped config)
SDDM's Wayland greeter runs its own separate Hyprland instance viaCompositorCommand=start-hyprland -- --config /usr/share/sddm/hyprland.lua
(from /etc/sddm.conf.d/10-wayland.conf). That config
(/usr/share/sddm/hyprland.lua, owned by the omarchy-settings package) only
sets:
hl.config({
misc = { disable_hyprland_logo = true, disable_splash_rendering = true, force_default_wallpaper = 0 },
animations = { enabled = false },
})
It has none of the machinery the real user session relies on for this exact
scenario:
- The switch:on:Lid Switch / switch:off:Lid Switch binds
(default/hypr/bindings/utilities.lua) that disable the internal panel and
re-sync the external monitor via omarchy-hyprland-monitor-clamshell.
- The Omarchy shell's idle service, whose activity handler calls
omarchy-system-wake -> hyprctl dispatch dpms enable +
omarchy-hyprland-monitor-clamshell re-sync on input.
So with the lid closed at the greeter, output state gets stuck and nothing
re-probes it on input. Physically opening/closing the lid forces a fresh
output reconfiguration, which is why that "fixes" it.
Steps to reproduce
- Laptop lid open, connect an external monitor, confirm clamshell mode
works (internal panel off, external monitor active).
2. Close the lid.
3. Log Out (not Lock).
4. Try to wake the external monitor with the mouse or keyboard.
-> Nothing happens. Only opening then closing the lid again restores
output.
Workaround
Using "Lock" (Super+Ctrl+L) instead of "Log Out" avoids the bug entirely,
since it stays inside the real Hyprland session, which already handles this
correctly.
System
- Omarchy 4.0.2-1
- Surface Pro 8, Intel i915 (TigerLake-LP GT2 Iris Xe)
- Hyprland 0.56.2, SDDM 0.21.0-7, Wayland greeter
omarchy debug --no-sudo --printlog available on request
View raw text
### What happened
On a laptop with the lid closed and an external monitor connected, the desktop
session correctly disables the internal panel and drives the external monitor
(clamshell mode). But after using "Log Out" (not Lock), moving the mouse or
pressing a key does not wake the external monitor. The only way to recover is
to physically open the lid and close it again.
### Expected
Mouse/keyboard input at the SDDM login screen should wake the external
monitor, the same way it does inside a normal Hyprland session with the lid
closed.
### Root cause (found by inspecting the shipped config)
SDDM's Wayland greeter runs its own separate Hyprland instance via
`CompositorCommand=start-hyprland -- --config /usr/share/sddm/hyprland.lua`
(from /etc/sddm.conf.d/10-wayland.conf). That config
(`/usr/share/sddm/hyprland.lua`, owned by the `omarchy-settings` package) only
sets:
hl.config({
misc = { disable_hyprland_logo = true, disable_splash_rendering = true, force_default_wallpaper = 0 },
animations = { enabled = false },
})
It has none of the machinery the real user session relies on for this exact
scenario:
- The `switch:on:Lid Switch` / `switch:off:Lid Switch` binds
(default/hypr/bindings/utilities.lua) that disable the internal panel and
re-sync the external monitor via `omarchy-hyprland-monitor-clamshell`.
- The Omarchy shell's idle service, whose activity handler calls
`omarchy-system-wake` -> `hyprctl dispatch dpms enable` +
`omarchy-hyprland-monitor-clamshell` re-sync on input.
So with the lid closed at the greeter, output state gets stuck and nothing
re-probes it on input. Physically opening/closing the lid forces a fresh
output reconfiguration, which is why that "fixes" it.
### Steps to reproduce
1. Laptop lid open, connect an external monitor, confirm clamshell mode
works (internal panel off, external monitor active).
2. Close the lid.
3. Log Out (not Lock).
4. Try to wake the external monitor with the mouse or keyboard.
-> Nothing happens. Only opening then closing the lid again restores
output.
### Workaround
Using "Lock" (Super+Ctrl+L) instead of "Log Out" avoids the bug entirely,
since it stays inside the real Hyprland session, which already handles this
correctly.
### System
- Omarchy 4.0.2-1
- Surface Pro 8, Intel i915 (TigerLake-LP GT2 Iris Xe)
- Hyprland 0.56.2, SDDM 0.21.0-7, Wayland greeter
- `omarchy debug --no-sudo --print` log available on requestValidation
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 10:54 UTC