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-209GitHub issuePublicDecided· Out of scope

linux-omarchy kernel: ACPI lid-close no longer emits evdev SW_LID event (ASUS Zenbook); stock 7.2.3 works

Reported by h0jack · filed Sep 22, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 3 days ago.

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

linux-omarchy kernel: ACPI lid-close no longer emits evdev SW_LID event (ASUS Zenbook); stock 7.2.3 worksrevision 1 · captured 2026-09-28 21:23 UTC via poll

Summary

Closing the laptop lid no longer emits an evdev lid-switch event on the linux-omarchy kernel, so nothing suspends. The same userspace stack on the stock Arch kernel (7.2.3-arch1-3) handles lid closes fine.

System

  • Host: ASUS Zenbook (ACPI Lid Switch at PNP0C0D:01, /dev/input/event0, EV_SW SW_LID only)
  • Working kernel: 7.2.3-arch1-3 (Arch stock, last booted Sep 21 14:44)
  • Broken kernel: 7.2.5-3-omarchy (first booted Sep 21 16:34, installed by omarchy 4.0.4 migration 1789325478)
  • Userspace identical across both boots (omarchy 4.0.4, systemd 261.2, Hyprland 0.56.2-2)

Steps to reproduce

  1. Boot 7.2.5-3-omarchy.
  2. Close the lid fully and hold for ~15 seconds, then open.

Expected

  • Kernel emits a lid-switch event; logged Lid closed.; systemd-logind suspends per HandleLidSwitch=suspend.

Actual

  • Nothing happens. No suspend, no Lid closed. log entry.
  • /proc/acpi/button/lid/LID/state does flip open → closed during the test, so the ACPI button driver detects the lid.

Diagnostics

  • systemd-logind at boot: Watching system buttons on /dev/input/event0 (Lid Switch) — but it logs no lid events the entire boot.
  • A root raw reader on /dev/input/event0 (fresh fd, opened during the lid close) received zero EV_SW/EV_KEY events in a 150s window that bracketed the physical close.
  • Hyprland registers the device as a switch but observes no switch event either.
  • EVIOCGRAB on /dev/input/event0 succeeds — no process is exclusively grabbing the device, so the events simply are not emitted to the input subsystem.
  • For comparison, on 7.2.3-arch1-3 the identical boot logs Lid closed./Lid opened. on every physical lid action and suspend works.

Conclusion

The ACPI button driver updates /proc/acpi/button/lid/*/state but fails to emit the accompanying input event (input_report_switch(..., SW_LID, ...) / sync) on linux-omarchy 7.2.5-3, at least on this ASUS Zenbook. Everything downstream (logind, compositor, any evdev reader) is starved of the lid event.

View raw text
## Summary

Closing the laptop lid no longer emits an evdev lid-switch event on the `linux-omarchy` kernel, so nothing suspends. The same userspace stack on the stock Arch kernel (`7.2.3-arch1-3`) handles lid closes fine.

## System

- Host: ASUS Zenbook (ACPI Lid Switch at `PNP0C0D:01`, `/dev/input/event0`, EV_SW `SW_LID` only)
- Working kernel: `7.2.3-arch1-3` (Arch stock, last booted Sep 21 14:44)
- Broken kernel: `7.2.5-3-omarchy` (first booted Sep 21 16:34, installed by omarchy 4.0.4 migration 1789325478)
- Userspace identical across both boots (omarchy 4.0.4, systemd 261.2, Hyprland 0.56.2-2)

## Steps to reproduce

1. Boot `7.2.5-3-omarchy`.
2. Close the lid fully and hold for ~15 seconds, then open.

## Expected

- Kernel emits a lid-switch event; logged `Lid closed.`; `systemd-logind` suspends per `HandleLidSwitch=suspend`.

## Actual

- Nothing happens. No suspend, no `Lid closed.` log entry.
- `/proc/acpi/button/lid/LID/state` **does** flip `open` → `closed` during the test, so the ACPI button driver detects the lid.

## Diagnostics

- `systemd-logind` at boot: `Watching system buttons on /dev/input/event0 (Lid Switch)` — but it logs **no** lid events the entire boot.
- A root raw reader on `/dev/input/event0` (fresh fd, opened during the lid close) received **zero** `EV_SW`/`EV_KEY` events in a 150s window that bracketed the physical close.
- Hyprland registers the device as a switch but observes no switch event either.
- `EVIOCGRAB` on `/dev/input/event0` **succeeds** — no process is exclusively grabbing the device, so the events simply are not emitted to the input subsystem.
- For comparison, on `7.2.3-arch1-3` the identical boot logs `Lid closed.`/`Lid opened.` on every physical lid action and suspend works.

## Conclusion

The ACPI button driver updates `/proc/acpi/button/lid/*/state` but fails to emit the accompanying input event (`input_report_switch(..., SW_LID, ...)` / sync) on `linux-omarchy 7.2.5-3`, at least on this ASUS Zenbook. Everything downstream (logind, compositor, any evdev reader) is starved of the lid event.

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 17:09 UTC