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.
Aether underpaints large Wayland allocations: content stuck ~1800x1200 top-left, rest transparent (Hyprland, AMD, scale 1)
Reported by kaibur02 · filed Sep 23, 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
Aether's window frame fills its tile/fullscreen allocation, but the app only
paints roughly the top-left ~1800x1200 and leaves the rest of the surface
transparent, showing the desktop wallpaper through. Screenshots (attached
separately, gh can't upload media) show the sharp cutoff on the right and
bottom edges.
This followed a fractional-scaling investigation: at monitor scale 1.6x
clicks were offset and fullscreen scroll repainted only the top-left ~1/1.6
region (classic GTK3/WebKit2GTK without wp-fractional-scale-v1). Moving both
monitors to integer scale 1x fixed input accuracy, but exposed this
underpainting, which the 1.6x compositor upscaling had been masking.
What was expected
Aether fills its full 2536x1390 tiled allocation (or 2560x1440 fullscreen)
like other apps on the same monitor (e.g. Stremio tiles and fills fine).
Steps to reproduce
- Two monitors at scale 1: DP-1 LG 2560x1440@165Hz, DP-2 ASUS 1920x1080@60Hz
- Launch Aether (native Wayland,
xwayland=False,GDK_SCALE=1) - Tile it on DP-1 (allocation 2536x1390) or fullscreen it (
SUPER+F, 2560x1440) - Observe: UI occupies ~top-left 2/3, desktop wallpaper visible around
the right and bottom; clicks within the painted area are accurate
Evidence
hyprctltiled:at=[3312, -29] size=[2536, 1390] floating=False fullscreen=0hyprctlfullscreen:at=[3300, -67] size=[2560, 1440] floating=True fullscreen=2
(compositor configure correct in both cases; client never paints bigger)
- Frontend fills by design (App.svelte root flex h-screen flex-col,
opaque body), main.go: Width 900 Height 700, resizable, no max size
- Screenshots: tiled overview + right-edge crop + bottom-edge crop (attached
via web form; files at /tmp/aether-tiled-small.png,
/tmp/aether-right.png, /tmp/aether-bottom.png)
System details
- Omarchy 4.0.4-1, Hyprland 0.56.2, Aether 4.29.9-1 (note: v4.30.0 exists
upstream but only adds wallpaper drag-and-drop per its release notes)
- webkit2gtk-4.1 2.52.6-1, gtk3 1:3.24.52-1, xorg-xwayland 24.1.13-1
- GPU: AMD Radeon RX 9070/9070 XT/9070 GRE (Navi 48) — not NVIDIA, so the
IsNvidiaWayland DMA-BUF workaround in main.go is inactive
- Wails v2 app (WebviewGpuPolicyNever, StartHidden: true)
Suspected cause
Wails v2 / webkit2gtk WebView not resizing to large Wayland configures:
small allocations (~1270px) fill, large ones (~2536px) underpaint. Needs an
app-side fix; no compositor workaround found (integer scaling already applied).
View raw text
## What happened Aether's window frame fills its tile/fullscreen allocation, but the app only paints roughly the top-left ~1800x1200 and leaves the rest of the surface transparent, showing the desktop wallpaper through. Screenshots (attached separately, `gh` can't upload media) show the sharp cutoff on the right and bottom edges. This followed a fractional-scaling investigation: at monitor scale 1.6x clicks were offset and fullscreen scroll repainted only the top-left ~1/1.6 region (classic GTK3/WebKit2GTK without wp-fractional-scale-v1). Moving both monitors to integer scale 1x fixed input accuracy, but exposed this underpainting, which the 1.6x compositor upscaling had been masking. ## What was expected Aether fills its full 2536x1390 tiled allocation (or 2560x1440 fullscreen) like other apps on the same monitor (e.g. Stremio tiles and fills fine). ## Steps to reproduce 1. Two monitors at scale 1: DP-1 LG 2560x1440@165Hz, DP-2 ASUS 1920x1080@60Hz 2. Launch Aether (native Wayland, `xwayland=False`, `GDK_SCALE=1`) 3. Tile it on DP-1 (allocation 2536x1390) or fullscreen it (`SUPER+F`, 2560x1440) 4. Observe: UI occupies ~top-left 2/3, desktop wallpaper visible around the right and bottom; clicks within the painted area are accurate ## Evidence - `hyprctl` tiled: `at=[3312, -29] size=[2536, 1390] floating=False fullscreen=0` - `hyprctl` fullscreen: `at=[3300, -67] size=[2560, 1440] floating=True fullscreen=2` (compositor configure correct in both cases; client never paints bigger) - Frontend fills by design (`App.svelte` root `flex h-screen flex-col`, opaque `body`), `main.go`: `Width 900 Height 700`, resizable, no max size - Screenshots: tiled overview + right-edge crop + bottom-edge crop (attached via web form; files at `/tmp/aether-tiled-small.png`, `/tmp/aether-right.png`, `/tmp/aether-bottom.png`) ## System details - Omarchy 4.0.4-1, Hyprland 0.56.2, Aether 4.29.9-1 (note: v4.30.0 exists upstream but only adds wallpaper drag-and-drop per its release notes) - webkit2gtk-4.1 2.52.6-1, gtk3 1:3.24.52-1, xorg-xwayland 24.1.13-1 - GPU: AMD Radeon RX 9070/9070 XT/9070 GRE (Navi 48) — not NVIDIA, so the `IsNvidiaWayland` DMA-BUF workaround in main.go is inactive - Wails v2 app (`WebviewGpuPolicyNever`, `StartHidden: true`) ## Suspected cause Wails v2 / webkit2gtk WebView not resizing to large Wayland configures: small allocations (~1270px) fill, large ones (~2536px) underpaint. Needs an app-side fix; no compositor workaround found (integer scaling already applied).
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 19:32 UTC