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

ThinkPad T480s: stale/frozen lock screen for ~30 s after S3 resume

Reported by hugo88 · filed Aug 26, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 4 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

ThinkPad T480s: stale/frozen lock screen for ~30 s after S3 resumerevision 1 · captured 2026-09-28 21:24 UTC via poll

System details

Lenovo ThinkPad T480s (20L8), Intel UHD 620 / i915, internal eDP-1 1920x1080@60; Hyprland 0.56.2-1, Aquamarine 0.14.0-2, Linux 7.1.9.arch1-2, Mesa 26.2.1-1.

What's wrong?

Summary

After lid-close suspend and resume, the lock-screen image remains visually frozen for about 30 seconds. Pointer movement and typed-password feedback are not drawn, but the machine is not actually stuck: entering the correct password and pressing Enter is accepted immediately, and the session becomes visible once the display recovers.

Steps to reproduce

  1. Lock the session normally.
  2. Close the lid to suspend.
  3. Open the lid.
  4. The locked image appears frozen: the pointer does not visibly move and password feedback is not drawn.
  5. Type the password and press Enter, then wait about 30 seconds.

Expected behavior

The lock screen should repaint and react to input immediately after resume.

Actual behavior

The visual output is frozen for about 30 seconds, while PAM authentication and session unlock occur in the same second as resume.

Evidence

The latest reproduction used S3 suspend:

20:42:56  Lid closed; preparing to enter S3
20:43:31  Lid opened
20:43:32  System returned from suspend
20:43:32  Omarchy PAM: Authenticated successfully
20:43:32  omarchy-shell: unlocked

There were no i915 DRM errors, OOM kills, compositor crashes, or core dumps around this resume.

What I tested

  • Replaced third-party Lock Screen Explorer with the stock omarchy.lock; manual lock works, while the resume failure remains.
  • Temporarily stopped hyprmoncfgd; the resume failure remained.
  • Moved the mouse/TrackPoint immediately after resume; it did not produce visible cursor movement or repaint.
  • I did not change i915 module parameters.

Related reports

View raw text
### System details

Lenovo ThinkPad T480s (20L8), Intel UHD 620 / i915, internal eDP-1 1920x1080@60; Hyprland 0.56.2-1, Aquamarine 0.14.0-2, Linux 7.1.9.arch1-2, Mesa 26.2.1-1.

### What's wrong?

### Summary

After lid-close suspend and resume, the lock-screen image remains visually frozen for about 30 seconds. Pointer movement and typed-password feedback are not drawn, but the machine is not actually stuck: entering the correct password and pressing Enter is accepted immediately, and the session becomes visible once the display recovers.

### Steps to reproduce

1. Lock the session normally.
2. Close the lid to suspend.
3. Open the lid.
4. The locked image appears frozen: the pointer does not visibly move and password feedback is not drawn.
5. Type the password and press Enter, then wait about 30 seconds.

### Expected behavior

The lock screen should repaint and react to input immediately after resume.

### Actual behavior

The visual output is frozen for about 30 seconds, while PAM authentication and session unlock occur in the same second as resume.

### Evidence

The latest reproduction used S3 suspend:

```text
20:42:56  Lid closed; preparing to enter S3
20:43:31  Lid opened
20:43:32  System returned from suspend
20:43:32  Omarchy PAM: Authenticated successfully
20:43:32  omarchy-shell: unlocked
```

There were no i915 DRM errors, OOM kills, compositor crashes, or core dumps around this resume.

### What I tested

- Replaced third-party Lock Screen Explorer with the stock `omarchy.lock`; manual lock works, while the resume failure remains.
- Temporarily stopped `hyprmoncfgd`; the resume failure remained.
- Moved the mouse/TrackPoint immediately after resume; it did not produce visible cursor movement or repaint.
- I did not change i915 module parameters.

### Related reports

- https://github.com/basecamp/omarchy/issues/5695 reports a similar 30-60 s resume delay, but on different hardware and with different i915 errors.
- https://github.com/hyprwm/Hyprland/discussions/15590 describes a possibly related Hyprland 0.56 stale-frame-on-resume regression. Its mouse-motion workaround does not work 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 02:25 UTC