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.
Samsung Smart Monitor (M5) over HDMI: random 1-4s blank/dim, Linux/Hyprland only — works fine on Windows
Reported by jaimelmsantos-ai · filed Sep 1, 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
Symptom
Screen randomly dims to black and back for 1-4 seconds on a mini PC (Intel N100 / Alder Lake-N, i915 iGPU) driving a Samsung M5 Smart Monitor over HDMI. Identical hardware (same PC, same monitor, same cable, same ports) ran fine under Windows with zero blanking — this only happens under Omarchy (Hyprland 0.56.2, Aquamarine 0.14.0).
Investigation so far
Used a custom logger sampling display/DRM/DPMS/HDMI-ELD/USB state every 0.2s, cross-referenced against user-marked blank events in real time.
16 confirmed blank events so far, 16 for 16 showing zero correlation with:
- DRM connector status (stays connected throughout)
- DPMS state (stays on)
- HDMI audio ELD (stays valid)
- USB device count (unchanged)
- Hyprland's own log (hyprland.log, tmpfs) — zero new lines during any blank, meaning the compositor performs no observable action (no commit, no modeset, nothing) during the events
Ruled out:
- Monitor OSD "Brightness Optimization" / "Motion Lighting"
- Monitor Smart Hub / Wi-Fi (disabled entirely, blanks continued unchanged)
- PC-side brightness daemons (none running — no DDC/CI, gammastep, hyprsunset, brightnessctl)
- Cable/port/monitor hardware defect (rules out via identical setup working fine on Windows)
- hyprwm/aquamarine#265 (per-frame connector-state commit causing HDMI renegotiation) — its fix (merged 2026-05-10) is already present in the installed aquamarine 0.14.0 (released 2026-07-27); also observed duration (1-4s) doesn't match that bug's ~0.2s single-frame signature
- cursor.no_hardware_cursors = true workaround (for an unrelated i915 hardware-cursor-plane flicker theory) — confirmed already active during multiple confirmed blanks, insufficient alone
Related but unresolved: #13338 has a very similar Samsung+Intel+HDMI+Hyprland combo, closed "not planned" after exhausting VFR/direct_scanout/refresh-rate/EDID tests.
Leading theory
Since it's Linux/Hyprland-specific and produces zero observable activity at the compositor or DRM-connector-status layer, this looks like it's happening below both of those — most likely a link-training/signal-integrity hiccup at the i915/TMDS level, or a PSR/backlight-PWM-related kernel driver issue, that never toggles HDMI hot-plug-detect (which is why nothing above the kernel driver sees it).
Next step
Planning to enable kernel-level DRM debug logging (/sys/module/drm/parameters/debug) to try to catch link-training/vblank/underrun events at the next occurrence, and will report back with findings.
Full personal tracking issue with more detail: jaimelmsantos-ai/Work#1
View raw text
## Symptom Screen randomly dims to black and back for 1-4 seconds on a mini PC (Intel N100 / Alder Lake-N, i915 iGPU) driving a Samsung M5 Smart Monitor over HDMI. Identical hardware (same PC, same monitor, same cable, same ports) ran fine under Windows with zero blanking — this only happens under Omarchy (Hyprland 0.56.2, Aquamarine 0.14.0). ## Investigation so far Used a custom logger sampling display/DRM/DPMS/HDMI-ELD/USB state every 0.2s, cross-referenced against user-marked blank events in real time. 16 confirmed blank events so far, 16 for 16 showing **zero correlation** with: - DRM connector status (stays `connected` throughout) - DPMS state (stays on) - HDMI audio ELD (stays valid) - USB device count (unchanged) - Hyprland's own log (`hyprland.log`, tmpfs) — zero new lines during any blank, meaning the compositor performs no observable action (no commit, no modeset, nothing) during the events Ruled out: - Monitor OSD "Brightness Optimization" / "Motion Lighting" - Monitor Smart Hub / Wi-Fi (disabled entirely, blanks continued unchanged) - PC-side brightness daemons (none running — no DDC/CI, gammastep, hyprsunset, brightnessctl) - Cable/port/monitor hardware defect (rules out via identical setup working fine on Windows) - hyprwm/aquamarine#265 (per-frame connector-state commit causing HDMI renegotiation) — its fix (merged 2026-05-10) is already present in the installed aquamarine 0.14.0 (released 2026-07-27); also observed duration (1-4s) doesn't match that bug's ~0.2s single-frame signature - `cursor.no_hardware_cursors = true` workaround (for an unrelated i915 hardware-cursor-plane flicker theory) — confirmed already active during multiple confirmed blanks, insufficient alone Related but unresolved: #13338 has a very similar Samsung+Intel+HDMI+Hyprland combo, closed "not planned" after exhausting VFR/direct_scanout/refresh-rate/EDID tests. ## Leading theory Since it's Linux/Hyprland-specific and produces zero observable activity at the compositor or DRM-connector-status layer, this looks like it's happening below both of those — most likely a link-training/signal-integrity hiccup at the i915/TMDS level, or a PSR/backlight-PWM-related kernel driver issue, that never toggles HDMI hot-plug-detect (which is why nothing above the kernel driver sees it). ## Next step Planning to enable kernel-level DRM debug logging (`/sys/module/drm/parameters/debug`) to try to catch link-training/vblank/underrun events at the next occurrence, and will report back with findings. Full personal tracking issue with more detail: jaimelmsantos-ai/Work#1
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:26 UTC