Repository navigation
Description
What happens
Nothing in the battery panel reads charge_control_end_threshold, so when a
charge limit is set on the hardware, the panel misreports it in two different
ways depending on the state of charge.
1. A cap on a nearly full battery is reported as no cap at all.
Model.chargeThresholdActive() infers whether a limit is in force from the
charge level and the UPower state rather than reading the threshold:
if (d.state === s.FullyCharged && fraction < 0.99) return true
if (d.state !== s.Charging || fraction >= 0.99) return falseWith the battery at 99% and a 60% cap applied, the state is FullyCharged and
the fraction is not below 0.99, so the second line returns false. The panel
shows "FULLY CHARGED" with "Time to full" and "Charging" rows, and no charge
limit row, while the firmware is holding a 60% cap and refusing to charge.
This is the normal state right after a limit is lowered, because lowering a cap
stops charging but does not discharge the battery. It can persist for days on a
machine that stays on mains.
2. When the panel does show a limit, the number comes from UPower and is not
the one in force.
omarchy-battery-status reads the threshold from UPower and falls back to
sysfs only when UPower returns nothing:
threshold_start=$(awk '/charge-start-threshold:/ ...' <<<"$battery_info")
threshold_end=$(awk '/charge-end-threshold:/ ...' <<<"$battery_info")
[[ -z $threshold_end ]] && threshold_end=$(cat "$power_supply_path"/BAT*/charge_control_end_threshold ...)UPower always returns something here, so the sysfs fallback is unreachable. On
this machine UPower reports a 75-80% pair alongside
ChargeThresholdEnabled = false. Those are the values UPower would apply if
something called EnableChargeThreshold, not a reading of the hardware.
Steps to reproduce
On a laptop whose kernel driver exposes charge_control_end_threshold, an ASUS
Zenbook with asus_nb_wmi in this case:
# Set a cap well below the current charge
echo 60 | sudo tee /sys/class/power_supply/BAT0/charge_control_end_threshold
cat /sys/class/power_supply/BAT0/charge_control_end_threshold # 60
cat /sys/class/power_supply/BAT0/status # Not charging
# UPower does not agree, and never did
upower -i /org/freedesktop/UPower/devices/battery_BAT0 | grep charge-
# charge-start-threshold: 75%
# charge-end-threshold: 80%
omarchy-battery-status --shell | grep threshold
# threshold 75-80%Then open the battery panel. At 99% charge it reports "FULLY CHARGED" with no
charge limit row.
Evidence that UPower is not reading the hardware
The 75-80% pair is not a stale cache. It does not track the hardware at all.
Driving the threshold through three values leaves UPower unchanged:
charge_control_end_threshold |
UPower charge-end-threshold |
|---|---|
| 60 | 80% |
| 70 | 80% |
| 95 | 80% |
ChargeThresholdEnabled stays false throughout, which is consistent: UPower
has not enabled a threshold, something else has.
There is also no way to make UPower re-read it from outside. Refresh() is not
implemented on org.freedesktop.UPower.Device, and raising a synthetic udev
change event on the battery does not move the value either.
Expected
The panel should report the limit the firmware is actually holding, and should
treat a limit as active whenever charge_control_end_threshold is below 100,
independent of the current charge level.
Suggested fix
Read charge_control_end_threshold first and treat UPower as the fallback
rather than the other way round. If UPower is kept as the primary source, gate
it on ChargeThresholdEnabled being true, since its threshold properties are
meaningless when it is false.
For Model.chargeThresholdActive(), the state of charge is not evidence about
whether a cap exists. A cap is active when the threshold is below 100, and a
battery sitting at 99% under a 60% cap is exactly the case the current
heuristic gets wrong.
System details
- Omarchy 4.0.2-1
- Kernel 7.1.9-arch1-2
- UPower 1.91.3 (client and daemon)
- ASUS Zenbook UX8402ZE,
asus_nb_wmiloaded, single battery BAT0 - Intel Core i9-12900H, Intel Iris Xe and NVIDIA RTX 3050 Ti Mobile
Activity
brightwalker25 commentedon Sep 5, 2026
Both panels on the same machine, 36 seconds apart. The charge limit is 60% in charge_control_end_threshold and status reads Not charging. The stock panel reports FULLY CHARGED with no charge limit row, because the battery is still sitting at 99%.
sayem314 commentedon Sep 5, 2026
@robosayem verify this issue and then check for any duplicate issue or any existing pr related to this
robosayem commentedon Sep 5, 2026
Verified — both claims reproduce in the code, and the UPower source confirms the reported behavior.
Claim 2 (wrong source).
bin/omarchy-battery-statuson quattro parsescharge-start-threshold/charge-end-thresholdfromupower -ifirst, and the sysfs fallback is gated on[[ -z $threshold_end ]]. On UPower 1.91.x those properties are always exported (installed as defaults 0/100 inup-device-supply.cand then written on every battery update fromUpBatteryInfo), so the fallback is unreachable. Reading UPower's source explains the stale values:UpBatteryInfo.charge_control_*is populated exclusively from theCHARGE_LIMITudev hwdb property (up_device_supply_battery_get_charge_control_limits()inup-device-supply-battery.c), never from the live sysfs attributes. That is why the 75-80 pair does not track the hardware and whyChargeThresholdEnabled=falsestays consistent — UPower only reports thresholds it set itself.Claim 1 (panel heuristic). The quoted lines match
shell/plugins/panels/power/Model.jsverbatim. With stateFullyChargedand fraction ≥ 0.99, line 61 returns false even under an active cap, so the panel shows FULLY CHARGED with no charge limit row. The suggested direction (a limit is active when the threshold is below 100, regardless of charge level) is correct.Duplicates and prior art — no exact duplicate, but the pieces of this issue are already partly tracked:
omarchy-battery-statustrusting UPower first. Cross-linking and fixing all three together would make sense.omarchy-battery-statushalf: reads sysfscharge_control_*before UPower, keeps UPower as fallback, and adds a test. It does not touch theModel.chargeThresholdActive()heuristic, so this issue's claim 1 is not covered by any open PR.pending-chargetreated as a charge-limit hold without checking the level: a failed battery reports "Holding at 75-80%" at 0% #7803 with PRs Treat pending-charge as a hold only inside a real charge limit #7915/Stop a stalled charge reading as a charge-limit hold #7895, and Power panel invents a "Charge limit / Holding" state on hardware with no charge-control support #10193, are the samechargeThresholdActive()heuristic family from other angles (pending-charge at 0%, stalled charge, invented holds). A rewrite of that function should account for those cases too.bjarneo commentedon Sep 21, 2026
Automated duplication check: this issue looks similar to #7374, which covers the same battery panel shows wrong charge limit. I keep that one open and close this one to keep the discussion in one place.
If you feel this is the wrong decision, please open the issue again with a note on the difference.