Proof Portal

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

Power panel reports fabricated 'Charge cycles: 0' on _BIF-only firmware

Reported by m4t3u5LP · filed Sep 18, 2026 · 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

Power panel reports fabricated 'Charge cycles: 0' on _BIF-only firmwarerevision 1 · captured 2026-09-28 21:23 UTC via poll

What happened

The power panel's "Charge cycles" field displays 0 on a machine whose ACPI
firmware implements only _BIF, which has no cycle-count field at all. The
value is not a reading — it is the kernel's initialized default surfaced as
fact. On this hardware the panel shows 0 regardless of the battery's true age.

UPower — which the same script already shells out to — correctly reports the
value as unknown for this battery:

$ upower -i $(upower -e | grep BAT) | grep charge-cycles
    charge-cycles:       N/A

$ cat /sys/class/power_supply/BAT0/cycle_count
0

$ sudo strings /sys/firmware/acpi/tables/DSDT | grep -o '_BIX\|_BIF' | sort | uniq -c
      2 _BIF

_BIX (ACPI 4.0) is what introduced the Cycle Count field; _BIF has no
equivalent. With no _BIX, the kernel has no source for the value.

Expected

"Charge cycles" shows — — the fallback already present in the code — when the
value is unavailable, matching what UPower reports for the same battery.

Where it comes from

  • bin/omarchy-battery-status:110-112 reads

/sys/class/power_supply/BAT*/cycle_count directly and emits the raw 0.
- shell/plugins/panels/power/Panel.qml:437:

  InfoPair { label: "Charge cycles"; value: root.batteryInfo.cycles || "—" }

The || "—" fallback only fires when the key is absent entirely (the script
omits the line when the file is unreadable). parseKeyValue in Model.js
stores values as strings, and "0" is truthy in JS, so the fallback never
fires for a zero value.

Possible fix

Filtering non-positive values in omarchy-battery-status would cover it:

[[ -n $cycles && $cycles -gt 0 ]] && printf 'cycles\t%s\n' "$cycles"

One tradeoff worth a maintainer's call: a battery with genuine _BIX support
that truly has 0 completed cycles would then show — instead of 0. UPower
makes exactly this tradeoff already (it maps <= 0 to unknown), so following
its lead seems defensible.

Steps to reproduce

  1. On a machine whose DSDT has no _BIX (verify with the grep above)
  2. Open the power panel from the bar
  3. "Charge cycles" reads 0

System

  • Omarchy 4.0.4-1
  • Dell Latitude 5491, BIOS 1.39.0
  • Intel Core i5-8400H / Intel UHD Graphics 630
  • Kernel 7.2.5-3-omarchy
  • Battery: SMP DELL GD1P653
View raw text
## What happened

The power panel's "Charge cycles" field displays `0` on a machine whose ACPI
firmware implements only `_BIF`, which has no cycle-count field at all. The
value is not a reading — it is the kernel's initialized default surfaced as
fact. On this hardware the panel shows `0` regardless of the battery's true age.

UPower — which the same script already shells out to — correctly reports the
value as unknown for this battery:

```
$ upower -i $(upower -e | grep BAT) | grep charge-cycles
    charge-cycles:       N/A

$ cat /sys/class/power_supply/BAT0/cycle_count
0

$ sudo strings /sys/firmware/acpi/tables/DSDT | grep -o '_BIX\|_BIF' | sort | uniq -c
      2 _BIF
```

`_BIX` (ACPI 4.0) is what introduced the Cycle Count field; `_BIF` has no
equivalent. With no `_BIX`, the kernel has no source for the value.

## Expected

"Charge cycles" shows `—` — the fallback already present in the code — when the
value is unavailable, matching what UPower reports for the same battery.

## Where it comes from

- `bin/omarchy-battery-status:110-112` reads
  `/sys/class/power_supply/BAT*/cycle_count` directly and emits the raw `0`.
- `shell/plugins/panels/power/Panel.qml:437`:

  ```qml
  InfoPair { label: "Charge cycles"; value: root.batteryInfo.cycles || "—" }
  ```

  The `|| "—"` fallback only fires when the key is absent entirely (the script
  omits the line when the file is unreadable). `parseKeyValue` in `Model.js`
  stores values as strings, and `"0"` is truthy in JS, so the fallback never
  fires for a zero value.

## Possible fix

Filtering non-positive values in `omarchy-battery-status` would cover it:

```bash
[[ -n $cycles && $cycles -gt 0 ]] && printf 'cycles\t%s\n' "$cycles"
```

One tradeoff worth a maintainer's call: a battery with genuine `_BIX` support
that truly has 0 completed cycles would then show `—` instead of `0`. UPower
makes exactly this tradeoff already (it maps `<= 0` to unknown), so following
its lead seems defensible.

## Steps to reproduce

1. On a machine whose DSDT has no `_BIX` (verify with the grep above)
2. Open the power panel from the bar
3. "Charge cycles" reads `0`

## System

- Omarchy 4.0.4-1
- Dell Latitude 5491, BIOS 1.39.0
- Intel Core i5-8400H / Intel UHD Graphics 630
- Kernel 7.2.5-3-omarchy
- Battery: SMP DELL GD1P653

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 15:42 UTC