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-4708GitHub issuePublicReceived

Battery percentage shows 0% on multi-battery systems (e.g. Surface Book)

Reported by jfluet · filed Aug 27, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #6885 (R-1856). GitHub close reason: completed.

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

Battery percentage shows 0% on multi-battery systems (e.g. Surface Book)revision 1 · captured 2026-10-04 12:03 UTC via poll

What happened

On a system with two battery devices reported to UPower (Microsoft Surface Book: one battery in the tablet/screen half, one in the keyboard base), the battery panel's percentage text shows 0% while the bar's icon and the panel's own progress bar correctly show the real charge level (~66%).

Expected behavior

The percentage text should match the progress bar / bar icon, both of which are already correct.

Root cause

omarchy-battery-status (/usr/share/omarchy/bin/omarchy-battery-status) selects a battery device with:

battery=$(upower -e 2>/dev/null | grep BAT | head -n 1)

This grabs whichever BAT* device sorts first alphabetically. On this system that's BAT1 — a phantom/empty device reporting energy-full: 0, percentage: 0%, state: pending-charge — instead of BAT2, the real battery at 66%.

Meanwhile, the bar widget and the panel's own progress bar (Panel.qml) source their values from UPower.displayDevice, which correctly aggregates across both battery devices to ~66%. So within the same panel, the big percentage number and the progress bar disagree.

Suggested fix

Have omarchy-battery-status use UPower's DisplayDevice (upower -i $(upower -e | grep DisplayDevice)) instead of the first raw BAT* device, matching what the QML side already does via UPower.displayDevice. This would also naturally handle any other multi-battery hardware.

System details

  • Omarchy version: 4.0.1-1
  • Hardware: Microsoft Surface Book (sys_vendor/product_name from DMI)
  • upower -e output:
  /org/freedesktop/UPower/devices/battery_BAT1
  /org/freedesktop/UPower/devices/battery_BAT2
  /org/freedesktop/UPower/devices/line_power_ADP1
  /org/freedesktop/UPower/devices/DisplayDevice
  • upower -i on BAT1 (wrongly selected): percentage: 0%, energy-full: 0 Wh, state: pending-charge
  • upower -i on BAT2 (real battery): percentage: 65.99%, energy-full: 52.157 Wh, state: discharging
  • upower -i on DisplayDevice (correct aggregate, matches the bar): percentage: 65.99%

Steps to reproduce

  1. On a system with more than one BAT* device in upower -e where a non-primary device reports stale/zero data
  2. Open the battery panel in the Omarchy bar
  3. Observe: progress bar and bar icon show the correct charge level, but the large percentage text shows 0%
View raw text
## What happened

On a system with two battery devices reported to UPower (Microsoft Surface Book: one battery in the tablet/screen half, one in the keyboard base), the battery panel's percentage text shows **0%** while the bar's icon and the panel's own progress bar correctly show the real charge level (~66%).

## Expected behavior

The percentage text should match the progress bar / bar icon, both of which are already correct.

## Root cause

`omarchy-battery-status` (`/usr/share/omarchy/bin/omarchy-battery-status`) selects a battery device with:

```bash
battery=$(upower -e 2>/dev/null | grep BAT | head -n 1)
```

This grabs whichever `BAT*` device sorts first alphabetically. On this system that's `BAT1` — a phantom/empty device reporting `energy-full: 0`, `percentage: 0%`, `state: pending-charge` — instead of `BAT2`, the real battery at 66%.

Meanwhile, the bar widget and the panel's own progress bar (`Panel.qml`) source their values from `UPower.displayDevice`, which correctly aggregates across both battery devices to ~66%. So within the same panel, the big percentage number and the progress bar disagree.

## Suggested fix

Have `omarchy-battery-status` use UPower's `DisplayDevice` (`upower -i $(upower -e | grep DisplayDevice)`) instead of the first raw `BAT*` device, matching what the QML side already does via `UPower.displayDevice`. This would also naturally handle any other multi-battery hardware.

## System details

- Omarchy version: 4.0.1-1
- Hardware: Microsoft Surface Book (`sys_vendor`/`product_name` from DMI)
- `upower -e` output:
  ```
  /org/freedesktop/UPower/devices/battery_BAT1
  /org/freedesktop/UPower/devices/battery_BAT2
  /org/freedesktop/UPower/devices/line_power_ADP1
  /org/freedesktop/UPower/devices/DisplayDevice
  ```
- `upower -i` on `BAT1` (wrongly selected): `percentage: 0%`, `energy-full: 0 Wh`, `state: pending-charge`
- `upower -i` on `BAT2` (real battery): `percentage: 65.99%`, `energy-full: 52.157 Wh`, `state: discharging`
- `upower -i` on `DisplayDevice` (correct aggregate, matches the bar): `percentage: 65.99%`

## Steps to reproduce

1. On a system with more than one `BAT*` device in `upower -e` where a non-primary device reports stale/zero data
2. Open the battery panel in the Omarchy bar
3. Observe: progress bar and bar icon show the correct charge level, but the large percentage text shows 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.