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

Screensaver doesn't dismiss on pointer/touchpad movement (only keyboard input or focus change)

Reported by Mik-pe · filed Sep 20, 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

Screensaver doesn't dismiss on pointer/touchpad movement (only keyboard input or focus change)revision 1 · captured 2026-09-28 21:23 UTC via poll

System details

  • Omarchy: 4.0.4-1
  • Kernel: 7.2.5-3-omarchy
  • CPU: Intel Core i5-1035G7
  • GPU: Intel Iris Plus Graphics G7

What happened

When the screensaver activates after the idle timeout, moving the touchpad does not dismiss it. The screensaver keeps running even though the user is actively interacting. It only goes away when:

  • a key is pressed (keyboard input), or
  • focus moves off the screensaver window (e.g. switching workspaces — which makes it look like the screensaver is "bound to a workspace")

Moving the touchpad while the screensaver is up neither dismisses the screensaver nor (visibly) does anything else; the screen stays on the screensaver animation.

What I expected

Pointer movement (touchpad/mouse) should dismiss the screensaver like keyboard input does. On a system where the primary input device is a touchpad, there is currently no natural way to wake the screen — users must either hit a key or switch workspaces.

Steps to reproduce

  1. Let the machine idle until the screensaver starts (default 150s).
  2. Move the touchpad (don't press any key).
  3. Screensaver keeps running. Note: the lock timer continues and will lock the session after the lock timeout while the user is touching the touchpad.
  4. Switching workspace (or pressing a key) dismisses it.

Analysis

omarchy-screensaver exits only on:

  • keyboard input: read -n1 -t 1 inside its event loop, or
  • focus loss: polling screensaver_in_focus (exits when hyprctl activewindow no longer reports org.omarchy.screensaver)

There is no pointer-motion trigger. Meanwhile the idle service (plugins/services/idle/Service.qml) intentionally keeps the idle cycle armed once the screensaver has started (handleActiveSignal ignores activity while screensaverStartedThisCycle), so compositor-reported activity from touchpad movement doesn't cancel the cycle either.

A possible fix: while the screensaver is running, treat compositor "active" idle-monitor transitions (pointer movement) as dismissal — i.e. cancel the idle cycle and kill the screensaver on idleMonitor.isIdle going false while screensaverWindowCount > 0. That would also fix the related problem of the lock timer firing while the user is actively moving the pointer.

View raw text
### System details

- Omarchy: 4.0.4-1
- Kernel: 7.2.5-3-omarchy
- CPU: Intel Core i5-1035G7
- GPU: Intel Iris Plus Graphics G7

### What happened

When the screensaver activates after the idle timeout, moving the touchpad does not dismiss it. The screensaver keeps running even though the user is actively interacting. It only goes away when:

- a key is pressed (keyboard input), or
- focus moves off the screensaver window (e.g. switching workspaces — which makes it look like the screensaver is "bound to a workspace")

Moving the touchpad while the screensaver is up neither dismisses the screensaver nor (visibly) does anything else; the screen stays on the screensaver animation.

### What I expected

Pointer movement (touchpad/mouse) should dismiss the screensaver like keyboard input does. On a system where the primary input device is a touchpad, there is currently no natural way to wake the screen — users must either hit a key or switch workspaces.

### Steps to reproduce

1. Let the machine idle until the screensaver starts (default 150s).
2. Move the touchpad (don't press any key).
3. Screensaver keeps running. Note: the lock timer continues and will lock the session after the lock timeout while the user is touching the touchpad.
4. Switching workspace (or pressing a key) dismisses it.

### Analysis

`omarchy-screensaver` exits only on:

- keyboard input: `read -n1 -t 1` inside its event loop, or
- focus loss: polling `screensaver_in_focus` (exits when `hyprctl activewindow` no longer reports `org.omarchy.screensaver`)

There is no pointer-motion trigger. Meanwhile the idle service (`plugins/services/idle/Service.qml`) intentionally keeps the idle cycle armed once the screensaver has started (`handleActiveSignal` ignores activity while `screensaverStartedThisCycle`), so compositor-reported activity from touchpad movement doesn't cancel the cycle either.

A possible fix: while the screensaver is running, treat compositor "active" idle-monitor transitions (pointer movement) as dismissal — i.e. cancel the idle cycle and kill the screensaver on `idleMonitor.isIdle` going false while `screensaverWindowCount > 0`. That would also fix the related problem of the lock timer firing while the user is actively moving the pointer.

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/11746· 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.

  • Out of scopeDecided by agents · verified · 2026-10-09 16:47 UTC