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 shows UPower's fixed ThinkPad default (75/80) instead of the real active charge threshold
Reported by ScytheAkira · filed Sep 1, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #7374 (R-1687). 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
What happened
The battery panel (and omarchy-battery-status) shows "Holding at 75-80%" for the charge threshold, but the actual active kernel charge threshold on my ThinkPad is 45%-65%.
What was expected
The panel/status string should reflect the real, active charge threshold.
Root cause
omarchy-battery-status derives the threshold from upower -i's charge-start-threshold / charge-end-threshold fields first, and only falls back to reading /sys/class/power_supply/BAT*/charge_control_{start,end}_threshold directly when those upower fields are empty:
https://github.com/basecamp/omarchy/blob/master/bin/omarchy-battery-status
On ThinkPad-class hardware, UPower's ChargeStartThreshold/ChargeEndThreshold D-Bus properties are a fixed built-in default (75/80) that UPower reports regardless of the real hardware state — they only reflect reality once ChargeThresholdEnabled has been toggled on via UPower's own EnableChargeThreshold method. Since UPower always returns a non-empty value for these fields (even when its own threshold management is inactive), the sysfs fallback in omarchy-battery-status never triggers, so real user-set thresholds (e.g. inherited from a prior TLP config, or set directly via sysfs) never show up.
Confirmed live on this machine:
$ cat /sys/class/power_supply/BAT0/charge_control_start_threshold
45
$ cat /sys/class/power_supply/BAT0/charge_control_end_threshold
65
$ gdbus introspect --system --dest org.freedesktop.UPower \
--object-path /org/freedesktop/UPower/devices/battery_BAT0 | grep -i threshold
readonly u ChargeStartThreshold = 75;
readonly u ChargeEndThreshold = 80;
readonly b ChargeThresholdEnabled = false;
readonly b ChargeThresholdSupported = true;
$ omarchy-battery-status
Battery 64% · Holding at 75-80% · 0W / 70WhThe true active threshold (45/65) only shows up if I ignore upower and read sysfs directly — but the script never gets there because upower's fields aren't empty.
Suggested fix
Prefer the live /sys/class/power_supply/BAT*/charge_control_{start,end}_threshold values over upower's fields when they disagree, or at minimum only trust upower's threshold fields when ChargeThresholdEnabled is true (readable via the same upower -i output as charge-threshold-enabled or via a D-Bus properties check).
Steps to reproduce
- On a ThinkPad (or other device with sysfs
charge_control_start_threshold/charge_control_end_thresholdsupport) with a custom threshold set directly via sysfs or a tool other than UPower's ownEnableChargeThreshold(e.g. TLP, or a manualecho N > charge_control_start_threshold). - Run
omarchy-battery-statusor open the battery panel. - Observe it reports 75-80% (or whatever UPower's fixed default is) instead of the real active threshold.
System details
- Omarchy: 4.0.2-1
- Kernel: 7.1.9-arch1-2
- Machine: Lenovo ThinkPad P15v Gen 1 (20TQ0045AD)
- Hyprland: 0.56.2
- UPower: 1.91.3
Full diagnostics: attached below.
omarchy-debug --no-sudo --print
$(cat /home/drligma/.claude/jobs/2bdf6353/tmp/omarchy-debug.log)View raw text
## What happened
The battery panel (and `omarchy-battery-status`) shows "Holding at 75-80%" for the charge threshold, but the *actual* active kernel charge threshold on my ThinkPad is 45%-65%.
## What was expected
The panel/status string should reflect the real, active charge threshold.
## Root cause
`omarchy-battery-status` derives the threshold from `upower -i`'s `charge-start-threshold` / `charge-end-threshold` fields first, and only falls back to reading `/sys/class/power_supply/BAT*/charge_control_{start,end}_threshold` directly when those upower fields are empty:
https://github.com/basecamp/omarchy/blob/master/bin/omarchy-battery-status
On ThinkPad-class hardware, UPower's `ChargeStartThreshold`/`ChargeEndThreshold` D-Bus properties are a **fixed built-in default (75/80)** that UPower reports regardless of the real hardware state — they only reflect reality once `ChargeThresholdEnabled` has been toggled on via UPower's own `EnableChargeThreshold` method. Since UPower always returns *a* non-empty value for these fields (even when its own threshold management is inactive), the sysfs fallback in `omarchy-battery-status` never triggers, so real user-set thresholds (e.g. inherited from a prior TLP config, or set directly via sysfs) never show up.
Confirmed live on this machine:
```
$ cat /sys/class/power_supply/BAT0/charge_control_start_threshold
45
$ cat /sys/class/power_supply/BAT0/charge_control_end_threshold
65
$ gdbus introspect --system --dest org.freedesktop.UPower \
--object-path /org/freedesktop/UPower/devices/battery_BAT0 | grep -i threshold
readonly u ChargeStartThreshold = 75;
readonly u ChargeEndThreshold = 80;
readonly b ChargeThresholdEnabled = false;
readonly b ChargeThresholdSupported = true;
$ omarchy-battery-status
Battery 64% · Holding at 75-80% · 0W / 70Wh
```
The true active threshold (45/65) only shows up if I ignore upower and read sysfs directly — but the script never gets there because upower's fields aren't empty.
## Suggested fix
Prefer the live `/sys/class/power_supply/BAT*/charge_control_{start,end}_threshold` values over upower's fields when they disagree, or at minimum only trust upower's threshold fields when `ChargeThresholdEnabled` is true (readable via the same `upower -i` output as `charge-threshold-enabled` or via a D-Bus properties check).
## Steps to reproduce
1. On a ThinkPad (or other device with sysfs `charge_control_start_threshold`/`charge_control_end_threshold` support) with a custom threshold set directly via sysfs or a tool other than UPower's own `EnableChargeThreshold` (e.g. TLP, or a manual `echo N > charge_control_start_threshold`).
2. Run `omarchy-battery-status` or open the battery panel.
3. Observe it reports 75-80% (or whatever UPower's fixed default is) instead of the real active threshold.
## System details
- Omarchy: 4.0.2-1
- Kernel: 7.1.9-arch1-2
- Machine: Lenovo ThinkPad P15v Gen 1 (20TQ0045AD)
- Hyprland: 0.56.2
- UPower: 1.91.3
Full diagnostics: attached below.
<details>
<summary>omarchy-debug --no-sudo --print</summary>
```
$(cat /home/drligma/.claude/jobs/2bdf6353/tmp/omarchy-debug.log)
```
</details>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.