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.
Screenshots include the mouse pointer on the NVIDIA output
Reported by rjwmtn · filed Oct 8, 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
System details
HP OMEN Transcend 14. Intel Arc 140T drives the internal panel (eDP-1); NVIDIA GeForce RTX 5060 Max-Q drives HDMI-A-1 (Dell S3422DWG). Both outputs are scale 1.6. Omarchy 4.0.4-1, Hyprland 0.56.2, hyprpicker 0.4.7, grim 1.5.0. cursor:no_hardware_cursors is 2 (auto).
What's wrong?
Press Print, drag a region, and the saved PNG contains the mouse pointer, clipped by a corner of the selection. Two region shots of the same page both have the themed pointer (#e68e0d / #0d0d0d) in the bottom-right corner. Shots that do not go through the screen freeze do not include it.
Expected: the picture matches the screen, without the pointer.
What is going on
omarchy-capture-screenshot forces cursor:no_hardware_cursors = 0, then omarchy-capture-region freezes the screen with hyprpicker -r -z, then grim copies that frozen frame.
grim on its own does not include the pointer. hyprpicker's zwlr_screencopy grab does, when the pointer is visible. For a drag, that pointer sits on a corner of the region, so the PNG shows a clipped cursor in the corner.
Forcing hardware cursors does not fix it on this machine.
- On the NVIDIA HDMI output, after
no_hardware_cursors = 0has settled, the freeze still contains a pointer sprite about 32px across. - On the Intel panel the same setting does keep the pointer out, but only after a frame has presented. The script sets the option and starts hyprpicker immediately, so that race still loses.
Hiding the pointer (cursor:invisible), waiting about 0.3s for hyprpicker to finish the grab, then showing the pointer again produces a frozen frame identical to a capture taken with the pointer hidden. The pointer is back for the rest of the selection.
Related
Discussion #5965 (crosshair left in the corner) was closed as fixed in Quattro. This still happens on 4.0.4.
#8240 is the other side of the same workaround: forcing hardware cursors hides the pointer during selection on nouveau and vmwgfx. That force is what this script uses, and on this NVIDIA output it does not keep the pointer out of the picture.
Dev's omarchy-capture-screenshot now execs omasnap, which 4.0.4 does not ship. Worth checking that omasnap's grab excludes the pointer too. omarchy-capture-region on dev still runs hyprpicker -r -z for the other capture tools.
Filed by Grok 4.7 via Grok Build.
View raw text
### System details HP OMEN Transcend 14. Intel Arc 140T drives the internal panel (eDP-1); NVIDIA GeForce RTX 5060 Max-Q drives HDMI-A-1 (Dell S3422DWG). Both outputs are scale 1.6. Omarchy 4.0.4-1, Hyprland 0.56.2, hyprpicker 0.4.7, grim 1.5.0. `cursor:no_hardware_cursors` is 2 (auto). ### What's wrong? Press Print, drag a region, and the saved PNG contains the mouse pointer, clipped by a corner of the selection. Two region shots of the same page both have the themed pointer (`#e68e0d` / `#0d0d0d`) in the bottom-right corner. Shots that do not go through the screen freeze do not include it. Expected: the picture matches the screen, without the pointer. ### What is going on `omarchy-capture-screenshot` forces `cursor:no_hardware_cursors = 0`, then `omarchy-capture-region` freezes the screen with `hyprpicker -r -z`, then grim copies that frozen frame. grim on its own does not include the pointer. hyprpicker's `zwlr_screencopy` grab does, when the pointer is visible. For a drag, that pointer sits on a corner of the region, so the PNG shows a clipped cursor in the corner. Forcing hardware cursors does not fix it on this machine. - On the NVIDIA HDMI output, after `no_hardware_cursors = 0` has settled, the freeze still contains a pointer sprite about 32px across. - On the Intel panel the same setting does keep the pointer out, but only after a frame has presented. The script sets the option and starts hyprpicker immediately, so that race still loses. Hiding the pointer (`cursor:invisible`), waiting about 0.3s for hyprpicker to finish the grab, then showing the pointer again produces a frozen frame identical to a capture taken with the pointer hidden. The pointer is back for the rest of the selection. ### Related Discussion #5965 (crosshair left in the corner) was closed as fixed in Quattro. This still happens on 4.0.4. #8240 is the other side of the same workaround: forcing hardware cursors hides the pointer during selection on nouveau and vmwgfx. That force is what this script uses, and on this NVIDIA output it does not keep the pointer out of the picture. Dev's `omarchy-capture-screenshot` now execs `omasnap`, which 4.0.4 does not ship. Worth checking that omasnap's grab excludes the pointer too. `omarchy-capture-region` on dev still runs `hyprpicker -r -z` for the other capture tools. Filed by Grok 4.7 via Grok Build.
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 22:54 UTC