Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-1415GitHub issuePublicReceived

Asahi MacBooks: lid handling can never fire — wrong switch name, and lid state read from /proc/acpi which Asahi lacks

Reported by GonzFC · filed Aug 26, 2026Closed upstream on 2026-10-08 by the bot omarchybot, as a duplicate of #8418 (R-1415). GitHub close reason: not_planned.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

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?
Not yet mapped to any requirement or component.
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?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

Asahi MacBooks: lid handling can never fire — wrong switch name, and lid state read from /proc/acpi which Asahi lacksrevision 1 · captured 2026-09-28 21:24 UTC via poll

On Asahi MacBooks, Omarchy's lid handling can never fire — for two independent reasons. A closed lid does nothing at all: the panel stays lit indefinitely, and omarchy-system-lid-close never runs.

Tested on two MacBook Air M1s (Asahi, Omarchy 4.0 Quattro, omarchy-dev 4.0.0.r6560).

1. The switch bind targets a device name Apple hardware does not use

default/hypr/bindings/utilities.lua:

o.bind("switch:on:Lid Switch", nil, "omarchy-system-lid-close", { locked = true })
o.bind("switch:off:Lid Switch", nil, "omarchy-hyprland-monitor-clamshell", { locked = true })

But hyprctl devices on these machines reports:

Switches:
	Switch Device at aaab301e2000:
		Apple SMC power/lid events

Lid Switch never matches, so neither bind fires.

2. omarchy-hw-laptop-closed reads a path Asahi does not provide

for state in /proc/acpi/button/lid/*/state; do
  [[ -r $state ]] || continue
  [[ $(< "$state") == *"closed"* ]] && exit 0
done
exit 1

Asahi has no ACPI. /proc/acpi/button/lid/ does not exist, so this always exits 1 — "lid is open", permanently. Even if the bind above fired, omarchy-system-lid-close would take no action, and omarchy-hw-clamshell can never be true.

The kernel does expose the switch, just not through ACPI:

$ cat /sys/class/input/input0/name
Apple SMC power/lid events
$ cat /sys/class/input/input0/capabilities/sw
1                     # bit 0 = SW_LID

Effect

With HandleLidSwitch=ignore in logind (as an always-on host wants), closing the lid leaves the internal panel at full backlight until some unrelated idle timer happens to fire — and never at all if anything keeps the session non-idle. Measured on this hardware: 6.61 W lid-closed-but-lit versus 1.66 W with the panel actually off.

Suggested fix

Two small changes, independent of each other:

  1. Match the lid switch by capability rather than by name — or bind both Lid Switch and the Apple name. Reading the device off hyprctl devices at config time also works.
  2. Give omarchy-hw-laptop-closed a non-ACPI fallback: find the input device whose capabilities/sw has bit 0 set and read SW_LID state from it, rather than assuming /proc/acpi.

Happy to open a PR for either or both if the shape sounds right — I have a working local implementation of the switch-name half.

View raw text
On Asahi MacBooks, Omarchy's lid handling can never fire — for two independent reasons. A closed lid does nothing at all: the panel stays lit indefinitely, and `omarchy-system-lid-close` never runs.

Tested on two MacBook Air M1s (Asahi, Omarchy 4.0 Quattro, `omarchy-dev 4.0.0.r6560`).

### 1. The switch bind targets a device name Apple hardware does not use

`default/hypr/bindings/utilities.lua`:

```lua
o.bind("switch:on:Lid Switch", nil, "omarchy-system-lid-close", { locked = true })
o.bind("switch:off:Lid Switch", nil, "omarchy-hyprland-monitor-clamshell", { locked = true })
```

But `hyprctl devices` on these machines reports:

```
Switches:
	Switch Device at aaab301e2000:
		Apple SMC power/lid events
```

`Lid Switch` never matches, so neither bind fires.

### 2. `omarchy-hw-laptop-closed` reads a path Asahi does not provide

```bash
for state in /proc/acpi/button/lid/*/state; do
  [[ -r $state ]] || continue
  [[ $(< "$state") == *"closed"* ]] && exit 0
done
exit 1
```

Asahi has no ACPI. `/proc/acpi/button/lid/` does not exist, so this always exits 1 — "lid is open", permanently. Even if the bind above fired, `omarchy-system-lid-close` would take no action, and `omarchy-hw-clamshell` can never be true.

The kernel does expose the switch, just not through ACPI:

```
$ cat /sys/class/input/input0/name
Apple SMC power/lid events
$ cat /sys/class/input/input0/capabilities/sw
1                     # bit 0 = SW_LID
```

### Effect

With `HandleLidSwitch=ignore` in logind (as an always-on host wants), closing the lid leaves the internal panel at full backlight until some unrelated idle timer happens to fire — and never at all if anything keeps the session non-idle. Measured on this hardware: 6.61 W lid-closed-but-lit versus 1.66 W with the panel actually off.

### Suggested fix

Two small changes, independent of each other:

1. Match the lid switch by capability rather than by name — or bind both `Lid Switch` and the Apple name. Reading the device off `hyprctl devices` at config time also works.
2. Give `omarchy-hw-laptop-closed` a non-ACPI fallback: find the input device whose `capabilities/sw` has bit 0 set and read `SW_LID` state from it, rather than assuming `/proc/acpi`.

Happy to open a PR for either or both if the shape sounds right — I have a working local implementation of the switch-name half.

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.

No decision has been recorded yet.