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-battery-status reports only the first battery (BAT0) on multi-battery systems
Reported by wari · filed Aug 23, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #6885 (R-1856). GitHub close reason: completed.
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
On laptops with two batteries (e.g. ThinkPad T460s with internal + bay battery), omarchy-battery-status — which backs the battery panel's percentage, time-remaining, rate, size, and cycle-count display — always reports data from BAT0 only, ignoring BAT1 entirely.
Root cause, in /usr/bin/omarchy-battery-status:
battery=$(upower -e 2>/dev/null | grep BAT | head -n 1)
...
battery_info=$(upower -i "$battery")
...
cycles=$(cat "$power_supply_path"/BAT*/cycle_count 2>/dev/null | head -1)Both the main upower -i query and the cycle_count fallback use head -1, silently discarding every battery past the first. UPower already exposes a combined /org/freedesktop/UPower/devices/DisplayDevice that correctly aggregates energy/percentage/state/rate — the Quickshell bar icon (UPower.displayDevice in Panel.qml) already uses it, but the panel's detail text (fed by this script) does not, so the two disagree.
A secondary issue: the cycle_count fallback reads raw sysfs directly, bypassing UPower's own charge-cycles field. UPower reports N/A when sysfs cycle_count is 0 (many firmwares, especially third-party replacement cells, never implement cycle counting and permanently report 0), but this script shows that raw 0 as if it were a real reading.
Repro:
$ upower -e | grep BAT
/org/freedesktop/UPower/devices/battery_BAT0
/org/freedesktop/UPower/devices/battery_BAT1
$ omarchy-battery-status --shell
percentage 31% # BAT0 only — combined DisplayDevice reports a different value
cycles 0 # UPower itself reports charge-cycles: N/A for this batterySuggested fix:
- When more than one BAT* device is present, query DisplayDevice instead of the first battery, and sum power_now/current_now*voltage_now across all BAT* sysfs entries for the instantaneous-rate override (since DisplayDevice has no single native-path).
- For cycle count, parse UPower's own charge-cycles field and honor N/A (omit the line) rather than falling back to a raw sysfs 0.
View raw text
On laptops with two batteries (e.g. ThinkPad T460s with internal + bay battery), `omarchy-battery-status` — which backs the battery panel's percentage, time-remaining, rate, size, and cycle-count display — always reports data from BAT0 only, ignoring BAT1 entirely. Root cause, in `/usr/bin/omarchy-battery-status`: ```bash battery=$(upower -e 2>/dev/null | grep BAT | head -n 1) ... battery_info=$(upower -i "$battery") ... cycles=$(cat "$power_supply_path"/BAT*/cycle_count 2>/dev/null | head -1) ``` Both the main `upower -i` query and the `cycle_count` fallback use `head -1`, silently discarding every battery past the first. UPower already exposes a combined `/org/freedesktop/UPower/devices/DisplayDevice` that correctly aggregates energy/percentage/state/rate — the Quickshell bar icon (`UPower.displayDevice` in `Panel.qml`) already uses it, but the panel's detail text (fed by this script) does not, so the two disagree. A secondary issue: the `cycle_count` fallback reads raw sysfs directly, bypassing UPower's own `charge-cycles` field. UPower reports `N/A` when sysfs `cycle_count` is `0` (many firmwares, especially third-party replacement cells, never implement cycle counting and permanently report 0), but this script shows that raw `0` as if it were a real reading. **Repro:** ``` $ upower -e | grep BAT /org/freedesktop/UPower/devices/battery_BAT0 /org/freedesktop/UPower/devices/battery_BAT1 $ omarchy-battery-status --shell percentage 31% # BAT0 only — combined DisplayDevice reports a different value cycles 0 # UPower itself reports charge-cycles: N/A for this battery ``` **Suggested fix:** - When more than one `BAT*` device is present, query `DisplayDevice` instead of the first battery, and sum `power_now`/`current_now*voltage_now` across all `BAT*` sysfs entries for the instantaneous-rate override (since `DisplayDevice` has no single `native-path`). - For cycle count, parse UPower's own `charge-cycles` field and honor `N/A` (omit the line) rather than falling back to a raw sysfs `0`.
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.