This issue description was created with the help of AI:
Environment:
- Device: MacBook Pro 13" (A2251, 2020, T2, Touch Bar)
- tiny-dfr version: 0.3.7-4-noble
- Distro / kernel: Ubuntu 24.04.4 LTS noble
- Install method: came with the t2-linux-noble installation
Description:
The Touch Bar battery widget ({ Battery = "percentage", Action = "Battery" } / "both") always displays 100%, regardless of actual charge level. Charging/discharging state (icon color) is reported correctly — only the percentage number is wrong.
Kernel-reported values are correct. Confirmed via sysfs directly:
$ cat /sys/class/power_supply/BAT0/uevent
DEVTYPE=power_supply
POWER_SUPPLY_NAME=BAT0
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_STATUS=Charging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Unknown
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=11440000
POWER_SUPPLY_VOLTAGE_NOW=12626000
POWER_SUPPLY_POWER_NOW=20302000
POWER_SUPPLY_ENERGY_FULL_DESIGN=50880000
POWER_SUPPLY_ENERGY_FULL=39670000
POWER_SUPPLY_ENERGY_NOW=33690000
POWER_SUPPLY_CAPACITY=85
POWER_SUPPLY_CAPACITY_LEVEL=Normal
POWER_SUPPLY_MODEL_NAME=bq20z451
POWER_SUPPLY_MANUFACTURER=SWDNz451
(ENERGY_NOW / ENERGY_FULL * 100 ≈ 85%, matching CAPACITY=85.)
The behavior persists identically on battery power (unplugged), ruling out any AC/charging-state branch as the cause.
Notably, charge_now / charge_full do not exist on this system at all — only the energy_* set:
$ ls /sys/class/power_supply/BAT0/
alarm capacity capacity_level cycle_count device energy_full
energy_full_design energy_now extensions hwmon1 manufacturer
model_name power power_now present serial_number status subsystem
technology type uevent voltage_min_design voltage_now
No other power_supply nodes exist besides BAT0 and ADP1 (Mains type, no capacity field), so device selection isn't the issue:
$ ls /sys/class/power_supply/
ADP1 BAT0
Hypothesis: the battery-percentage code path may assume/prefer charge_now/charge_full and, when those attributes are absent, falls back to (or defaults to) 100% instead of using energy_now/energy_full. Worth noting other T2 Macs with the same battery chip (bq20z451) have been reported elsewhere to expose charge_* attributes, so this seems to be a kernel/driver-version difference in which fields get populated, rather than something unique to the hardware.
Expected behavior: Touch Bar percentage should match energy_now / energy_full * 100 (or capacity) when charge_* attributes aren't present.
Actual behavior: Percentage always shows 100%, regardless of real charge level or AC state.
This issue description was created with the help of AI:
Environment:
Description:
The Touch Bar battery widget (
{ Battery = "percentage", Action = "Battery" }/"both") always displays 100%, regardless of actual charge level. Charging/discharging state (icon color) is reported correctly — only the percentage number is wrong.Kernel-reported values are correct. Confirmed via sysfs directly:
(
ENERGY_NOW / ENERGY_FULL * 100≈ 85%, matchingCAPACITY=85.)The behavior persists identically on battery power (unplugged), ruling out any AC/charging-state branch as the cause.
Notably,
charge_now/charge_fulldo not exist on this system at all — only theenergy_*set:No other power_supply nodes exist besides
BAT0andADP1(Mains type, no capacity field), so device selection isn't the issue:Hypothesis: the battery-percentage code path may assume/prefer
charge_now/charge_fulland, when those attributes are absent, falls back to (or defaults to) 100% instead of usingenergy_now/energy_full. Worth noting other T2 Macs with the same battery chip (bq20z451) have been reported elsewhere to exposecharge_*attributes, so this seems to be a kernel/driver-version difference in which fields get populated, rather than something unique to the hardware.Expected behavior: Touch Bar percentage should match
energy_now / energy_full * 100(orcapacity) whencharge_*attributes aren't present.Actual behavior: Percentage always shows 100%, regardless of real charge level or AC state.