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

power bar widget: charging icon lags plug-in by seconds and sticks on fake 'Holding'

Reported by sarniva · filed Oct 7, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 2 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

power bar widget: charging icon lags plug-in by seconds and sticks on fake 'Holding'revision 1 · captured 2026-10-07 20:18 UTC via poll

What happens

On my laptop the topbar battery icon reacts very late when the charger is plugged in (measured up to ~24s in one run; usually 5s+), and after my own testing it also gets stuck showing a plain icon with the panel reporting "Holding"/"Threshold" even at low charge (e.g. 29%).

What I expected

Plugging in AC shows the charging (thunder) icon within a second, and "Holding" only appears when a real charge limit is configured.

Measurements (5Hz log of sysfs vs UPower during a plug-in)

  • acad (/sys/class/power_supply/ACAD/online) flips 0 -> 1 and UPower OnBattery flips true -> false in the same <0.3s sample: kernel and UPower core property are fast.
  • UPower battery/DisplayDevice State only reaches Charging much later (it transitions Discharging -> Not charging (sysfs) -> PendingCharge (UPower) -> Charging), which is what the bar icon effectively waits on.
  • While charging, upower reports energy-rate: 0 W for extended periods.

Root causes (stock omarchy.power)

  1. Panel.qml derives the icon purely from UPower.onBattery / DisplayDevice.state, never from the instant sysfs AC state (omarchy-power-present already implements that check and stays unused by the widget).
  2. Model.js chargeThresholdActive() treats changeRate <= 0.2W (or timeToFull >= 8h) as "holding at charge limit". On hardware without instantaneous power telemetry this is permanently true while charging, so the thunder is suppressed and the panel shows a bogus "Holding".

Hardware details

  • HP Laptop 15s-eq2xxx (AMD Ryzen 3 5300U), Omarchy 4.0.4-1, UPower daemon 1.91.3, Quickshell 0.3.1
  • No /sys/class/power_supply/BAT0/charge_control_* files (charge limits impossible on this machine)
  • BAT0/power_now is listed but unreadable (No such device on read), current_now absent, so UPower's energy-rate lags/sits at 0

Reproduce

  1. On affected hardware (no charge thresholds, no power telemetry), unplug and replug AC
  2. Watch the topbar power icon: it stays plain long after cat /sys/class/power_supply/ACAD/online reads 1
  3. Open the power panel: it reports "Holding"/"Threshold" at low percentages with no limit configured

Suggestion

Drive the bar icon from the sysfs AC state (e.g. poll omarchy-power-present like my local clone does — thunder now appears in <1s), and gate the threshold heuristic on real configured limits instead of the laggy energy-rate. Happy to test a fix on this hardware.

View raw text
## What happens

On my laptop the topbar battery icon reacts very late when the charger is plugged in (measured up to ~24s in one run; usually 5s+), and after my own testing it also gets stuck showing a plain icon with the panel reporting "Holding"/"Threshold" even at low charge (e.g. 29%).

## What I expected

Plugging in AC shows the charging (thunder) icon within a second, and "Holding" only appears when a real charge limit is configured.

## Measurements (5Hz log of sysfs vs UPower during a plug-in)

- `acad` (`/sys/class/power_supply/ACAD/online`) flips `0 -> 1` and UPower `OnBattery` flips `true -> false` in the same <0.3s sample: kernel and UPower core property are fast.
- UPower battery/`DisplayDevice` `State` only reaches `Charging` much later (it transitions `Discharging -> Not charging (sysfs) -> PendingCharge (UPower) -> Charging`), which is what the bar icon effectively waits on.
- While charging, `upower` reports `energy-rate: 0 W` for extended periods.

## Root causes (stock `omarchy.power`)

1. `Panel.qml` derives the icon purely from `UPower.onBattery` / `DisplayDevice.state`, never from the instant sysfs AC state (`omarchy-power-present` already implements that check and stays unused by the widget).
2. `Model.js chargeThresholdActive()` treats `changeRate <= 0.2W` (or `timeToFull >= 8h`) as "holding at charge limit". On hardware without instantaneous power telemetry this is permanently true while charging, so the thunder is suppressed and the panel shows a bogus "Holding".

## Hardware details

- HP Laptop 15s-eq2xxx (AMD Ryzen 3 5300U), Omarchy 4.0.4-1, UPower daemon 1.91.3, Quickshell 0.3.1
- No `/sys/class/power_supply/BAT0/charge_control_*` files (charge limits impossible on this machine)
- `BAT0/power_now` is listed but unreadable (`No such device` on read), `current_now` absent, so UPower's energy-rate lags/sits at 0

## Reproduce

1. On affected hardware (no charge thresholds, no power telemetry), unplug and replug AC
2. Watch the topbar power icon: it stays plain long after `cat /sys/class/power_supply/ACAD/online` reads `1`
3. Open the power panel: it reports "Holding"/"Threshold" at low percentages with no limit configured

## Suggestion

Drive the bar icon from the sysfs AC state (e.g. poll `omarchy-power-present` like my local clone does — thunder now appears in <1s), and gate the threshold heuristic on real configured limits instead of the laggy energy-rate. Happy to test a fix on this hardware.

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:26 UTC