Skip to content

Battery panel ignores charge_control_end_threshold and misreports the charge limit #10344

Closed

Description

@brightwalker25

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 false

With 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_wmi loaded, single battery BAT0
  • Intel Core i9-12900H, Intel Iris Xe and NVIDIA RTX 3050 Ti Mobile

Activity

  1. brightwalker25 commented on Sep 5, 2026

    @brightwalker25
    Author
    Image Image

    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%.

  2. sayem314 commented on Sep 5, 2026

    @sayem314

    @robosayem verify this issue and then check for any duplicate issue or any existing pr related to this

  3. robosayem commented on Sep 5, 2026

    @robosayem

    Verified — both claims reproduce in the code, and the UPower source confirms the reported behavior.

    Claim 2 (wrong source). bin/omarchy-battery-status on quattro parses charge-start-threshold/charge-end-threshold from upower -i first, 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 in up-device-supply.c and then written on every battery update from UpBatteryInfo), so the fallback is unreachable. Reading UPower's source explains the stale values: UpBatteryInfo.charge_control_* is populated exclusively from the CHARGE_LIMIT udev hwdb property (up_device_supply_battery_get_charge_control_limits() in up-device-supply-battery.c), never from the live sysfs attributes. That is why the 75-80 pair does not track the hardware and why ChargeThresholdEnabled=false stays consistent — UPower only reports thresholds it set itself.

    Claim 1 (panel heuristic). The quoted lines match shell/plugins/panels/power/Model.js verbatim. With state FullyCharged and 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:

  4. bjarneo commented on Sep 21, 2026

    @bjarneo
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions