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.
Activity (btop) wakes a suspended NVIDIA dGPU on every open — Omarchy's btop.conf sets shown_gpus = "nvidia amd intel", which initialises NVML on hybrid laptops
Reported by Hazakins · filed Sep 10, 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
Summary. Omarchy binds Activity (Super+Ctrl+T) to btop and ships config/btop/btop.conf with shown_gpus = "nvidia amd intel" (line 254). btop 1.4.7 initialises NVML at startup whenever shown_gpus contains nvidia, whether or not a GPU box is displayed. On an iGPU-driven hybrid laptop that resumes the discrete GPU every time Activity is opened.
Environment. Omarchy 4.0.3-1, Hyprland 0.56.2-2, Arch, kernel 7.2.3-arch1-3. Framework Laptop 16, Ryzen AI 9 HX 370 / Radeon 890M (amdgpu, drives all outputs) + RTX 5070 graphics module (nvidia 610.57.04), no connector in use. btop 1.4.7.
Measured, watching /sys/bus/pci/devices/<dGPU>/power/runtime_status with the card suspended, btop launched in a pty with a scratch XDG_CONFIG_HOME:
| config | dGPU |
|---|---|
| Omarchy's btop.conf as shipped (no GPU box) | resuming ~2 s after launch, active while open, re-suspended ~15 s after exit |
same file with shown_gpus = "amd" and a gpu0 box added | suspended throughout |
The stock run had no GPU box, so this is the NVML init itself, not the display; the AMD-only run had a GPU box on and still never woke the card.
Cost. The 5070 leaves runtime suspend for as long as Activity is open, on battery included.
Suggestion. Default shown_gpus = "amd intel" (or omit nvidia) where NVIDIA drives no display — the same "does NVIDIA own the screen" question as #8215/#9483, applied to the monitor rather than the env. AMD load/VRAM from sysfs costs nothing.
Note: btop's own /proc/<pid> is unreadable to its owner (file capabilities), so measure the card's runtime_status, not btop's fds.
Disclosure: this diagnosis and write-up were produced by Claude (Fable 5.1, via Claude Code) working on my laptop; the measurements are from my machine and I reviewed the text before posting.
View raw text
**Summary.** Omarchy binds Activity (`Super+Ctrl+T`) to btop and ships `config/btop/btop.conf` with `shown_gpus = "nvidia amd intel"` (line 254). btop 1.4.7 initialises NVML at startup whenever `shown_gpus` contains `nvidia`, whether or not a GPU box is displayed. On an iGPU-driven hybrid laptop that resumes the discrete GPU every time Activity is opened. **Environment.** Omarchy 4.0.3-1, Hyprland 0.56.2-2, Arch, kernel 7.2.3-arch1-3. Framework Laptop 16, Ryzen AI 9 HX 370 / Radeon 890M (`amdgpu`, drives all outputs) + RTX 5070 graphics module (nvidia 610.57.04), no connector in use. btop 1.4.7. **Measured**, watching `/sys/bus/pci/devices/<dGPU>/power/runtime_status` with the card `suspended`, btop launched in a pty with a scratch `XDG_CONFIG_HOME`: | config | dGPU | |---|---| | Omarchy's btop.conf as shipped (no GPU box) | `resuming` ~2 s after launch, `active` while open, re-suspended ~15 s after exit | | same file with `shown_gpus = "amd"` and a `gpu0` box added | `suspended` throughout | The stock run had no GPU box, so this is the NVML init itself, not the display; the AMD-only run had a GPU box on and still never woke the card. **Cost.** The 5070 leaves runtime suspend for as long as Activity is open, on battery included. **Suggestion.** Default `shown_gpus = "amd intel"` (or omit `nvidia`) where NVIDIA drives no display — the same "does NVIDIA own the screen" question as #8215/#9483, applied to the monitor rather than the env. AMD load/VRAM from sysfs costs nothing. Note: btop's own `/proc/<pid>` is unreadable to its owner (file capabilities), so measure the card's `runtime_status`, not btop's fds. --- *Disclosure: this diagnosis and write-up were produced by Claude (Fable 5.1, via Claude Code) working on my laptop; the measurements are from my machine and I reviewed the text before posting.*
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 11:31 UTC