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.
omarchy-hw-external-monitors false positive from tiny-dfr Touch Bar DRM device causes lid-close lock to silently fail (T2 Macs)
Reported by kutassy · filed Sep 7, 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
On a T2 Mac (MacBookPro15,2) running tiny-dfr for Touch Bar support, closing the laptop lid never locks the screen. omarchy-system-lid-close gates the lock behind:
if omarchy-hw-laptop-closed && ! omarchy-hw-external-monitors; then
omarchy-system-lock
fiomarchy-hw-external-monitors reads raw DRM connector status files under /sys/class/drm/card*-*/status, excluding only eDP/LVDS/DSI connectors as "internal". tiny-dfr (the standard T2 Touch Bar daemon, from the arch-mact2/t2linux repo — not part of Omarchy) exposes the Touch Bar as its own DRM card via a virtual USB bridge (t2bce_core), e.g. card2-USB-2, which always reports status: connected since it's a permanently attached component, not a removable external display. This makes omarchy-hw-external-monitors always return true on these machines, so the lid-close lock never fires.
Evidence
$ cat /sys/class/drm/card2-USB-2/status
connected
$ readlink -f /sys/class/drm/card2-USB-2/device
/sys/devices/pci0000:00/0000:00:1d.4/0000:02:00.1/t2bce_core/t2bce_core/t2bce_vhci/usb7/7-6/7-6:2.1/drm/card2
$ hyprctl monitors all -j | jq -r '.[].name'
eDP-1Hyprland itself never manages that DRM device as a monitor, so omarchy-hyprland-monitor-external-active (already used elsewhere, e.g. omarchy-hyprland-monitor-clamshell) correctly returns false and doesn't have this false positive.
Expected
Closing the lid should lock the screen when no real external display is attached, same as on non-T2 hardware.
Suggested fix
Have omarchy-system-lid-close's lock decision use omarchy-hyprland-monitor-external-active (Hyprland's own monitor list) instead of / in addition to omarchy-hw-external-monitors, matching what omarchy-hyprland-monitor-clamshell already does for the equivalent decision. Alternatively, have omarchy-hw-external-monitors exclude DRM devices whose backing driver is a virtual/bridge device (tiny-dfr's Touch Bar) rather than only filtering by connector-name prefix.
System details
- Omarchy version: 4.0.2-1
- Hardware: MacBook Pro 15,2 (T2), linux-t2 kernel
- Touch Bar daemon: tiny-dfr (arch-mact2 repo), not part of Omarchy — installed separately for T2 Touch Bar support
- Full
omarchy debug --no-sudo --printoutput available on request
Workaround
Locally overrode the switch:on:Lid Switch binding to call a copy of omarchy-system-lid-close with the lock condition swapped to use omarchy-hyprland-monitor-external-active.
View raw text
## What happened On a T2 Mac (MacBookPro15,2) running tiny-dfr for Touch Bar support, closing the laptop lid never locks the screen. `omarchy-system-lid-close` gates the lock behind: ```bash if omarchy-hw-laptop-closed && ! omarchy-hw-external-monitors; then omarchy-system-lock fi ``` `omarchy-hw-external-monitors` reads raw DRM connector `status` files under `/sys/class/drm/card*-*/status`, excluding only `eDP`/`LVDS`/`DSI` connectors as "internal". tiny-dfr (the standard T2 Touch Bar daemon, from the arch-mact2/t2linux repo — not part of Omarchy) exposes the Touch Bar as its own DRM card via a virtual USB bridge (`t2bce_core`), e.g. `card2-USB-2`, which always reports `status: connected` since it's a permanently attached component, not a removable external display. This makes `omarchy-hw-external-monitors` always return true on these machines, so the lid-close lock never fires. ## Evidence ``` $ cat /sys/class/drm/card2-USB-2/status connected $ readlink -f /sys/class/drm/card2-USB-2/device /sys/devices/pci0000:00/0000:00:1d.4/0000:02:00.1/t2bce_core/t2bce_core/t2bce_vhci/usb7/7-6/7-6:2.1/drm/card2 $ hyprctl monitors all -j | jq -r '.[].name' eDP-1 ``` Hyprland itself never manages that DRM device as a monitor, so `omarchy-hyprland-monitor-external-active` (already used elsewhere, e.g. `omarchy-hyprland-monitor-clamshell`) correctly returns false and doesn't have this false positive. ## Expected Closing the lid should lock the screen when no real external display is attached, same as on non-T2 hardware. ## Suggested fix Have `omarchy-system-lid-close`'s lock decision use `omarchy-hyprland-monitor-external-active` (Hyprland's own monitor list) instead of / in addition to `omarchy-hw-external-monitors`, matching what `omarchy-hyprland-monitor-clamshell` already does for the equivalent decision. Alternatively, have `omarchy-hw-external-monitors` exclude DRM devices whose backing driver is a virtual/bridge device (tiny-dfr's Touch Bar) rather than only filtering by connector-name prefix. ## System details - Omarchy version: 4.0.2-1 - Hardware: MacBook Pro 15,2 (T2), linux-t2 kernel - Touch Bar daemon: tiny-dfr (arch-mact2 repo), not part of Omarchy — installed separately for T2 Touch Bar support - Full `omarchy debug --no-sudo --print` output available on request ## Workaround Locally overrode the `switch:on:Lid Switch` binding to call a copy of `omarchy-system-lid-close` with the lock condition swapped to use `omarchy-hyprland-monitor-external-active`.
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 02:18 UTC