Proof Portal

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

Plymouth: LUKS unlock entry field rendered off-screen for full-screen logos

Reported by org-tekeli-borisp · filed Sep 4, 2026 · 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

Plymouth: LUKS unlock entry field rendered off-screen for full-screen logosrevision 1 · captured 2026-09-28 21:24 UTC via poll

System details

  • Omarchy: 4.0.2-1 - Kernel: 7.1.9-arch1-2 - GPU: NVIDIA

What's wrong?

Summary

When a full-screen logo (matching the display resolution, e.g. 1920x1080) is set with omarchy plymouth set, the LUKS unlock screen's password entry field is positioned below the bottom edge of the screen and is no longer (fully) visible. Only a sliver of the top of the field shows, making the unlock prompt hard or impossible to use.

Steps to reproduce

  1. Prepare a PNG matching your display resolution (e.g. 1920x1080).
  2. omarchy plymouth set '#000000' '#ffffff' /path/to/wallpaper.png
  3. Reboot and let the LUKS unlock screen appear.
  4. Observe: the password entry field is pushed off the bottom of the screen.

Expected behaviour

The password entry field should remain fully on-screen regardless of the logo size.

Root cause

default/plymouth/omarchy.script computes the entry field's Y position relative to the logo's bottom edge, with no clamping to the window bounds:

entry.y = logo.sprite.GetY() + logo.image.GetHeight() + 40;

For a full-screen logo (logo height == window height) this evaluates to entry.y = window_height + 40, i.e. below the visible area. The lock icon and the password bullets are positioned relative to entry.y, so they go off-screen as well.

Suggested fix

Clamp entry.y so the field stays on-screen. This leaves the default (small-logo) layout unchanged and only kicks in for large logos:

entry.y = logo.sprite.GetY() + logo.image.GetHeight() + 40;
entry_max_y = Window.GetHeight() - entry.image.GetHeight() - 40;
if (entry.y > entry_max_y) entry.y = entry_max_y;

Related

omarchy plymouth preview uses the same unclamped formula (entry_y = logo_y + logo_h + 40), so its preview also drops the field off-canvas for full-screen logos and does not match the actual (fixed) boot screen.

System

  • Omarchy: 4.0.2-1
  • Kernel: 7.1.9-arch1-2
  • GPU: NVIDIA

<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/637a614c-063a-4dda-8f13-1517e877428a" />
<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/626e9fe4-a311-4061-b7b5-e6150035cebc" />

View raw text
### System details

- Omarchy: 4.0.2-1 - Kernel: 7.1.9-arch1-2 - GPU: NVIDIA

### What's wrong?

## Summary

When a full-screen logo (matching the display resolution, e.g. 1920x1080) is set with `omarchy plymouth set`, the LUKS unlock screen's password entry field is positioned below the bottom edge of the screen and is no longer (fully) visible. Only a sliver of the top of the field shows, making the unlock prompt hard or impossible to use.

## Steps to reproduce

1. Prepare a PNG matching your display resolution (e.g. 1920x1080).
2. `omarchy plymouth set '#000000' '#ffffff' /path/to/wallpaper.png`
3. Reboot and let the LUKS unlock screen appear.
4. Observe: the password entry field is pushed off the bottom of the screen.

## Expected behaviour

The password entry field should remain fully on-screen regardless of the logo size.

## Root cause

`default/plymouth/omarchy.script` computes the entry field's Y position relative to the logo's bottom edge, with no clamping to the window bounds:

```
entry.y = logo.sprite.GetY() + logo.image.GetHeight() + 40;
```

For a full-screen logo (logo height == window height) this evaluates to `entry.y = window_height + 40`, i.e. below the visible area. The lock icon and the password bullets are positioned relative to `entry.y`, so they go off-screen as well.

## Suggested fix

Clamp `entry.y` so the field stays on-screen. This leaves the default (small-logo) layout unchanged and only kicks in for large logos:

```
entry.y = logo.sprite.GetY() + logo.image.GetHeight() + 40;
entry_max_y = Window.GetHeight() - entry.image.GetHeight() - 40;
if (entry.y > entry_max_y) entry.y = entry_max_y;
```

## Related

`omarchy plymouth preview` uses the same unclamped formula (`entry_y = logo_y + logo_h + 40`), so its preview also drops the field off-canvas for full-screen logos and does not match the actual (fixed) boot screen.

## System

- Omarchy: 4.0.2-1
- Kernel: 7.1.9-arch1-2
- GPU: NVIDIA

<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/637a614c-063a-4dda-8f13-1517e877428a" />
<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/626e9fe4-a311-4061-b7b5-e6150035cebc" />
  • 637a614c-063a-4dda-8f13-1517e877428a
  • 626e9fe4-a311-4061-b7b5-e6150035cebc

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 10:48 UTC