Created attachment 39846 [details] `upower -d` when running on battery The behaviour of upower is as follows: if (AC power is connected): if (battery is not full): status is "charging" else: status is "discharging" else: status is "discharging" i.e., upower never shows the battery to be "full". I noticed that the same behaviour is exhibited by the "charge*" parameters exported in /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT1 , so, I tried to track this down to the ACPI battery driver (drivers/acpi/battery.c). By sprinkling printk()s around, I found that `battery->state` in acpi_battery_get_property() is set to 0x01 (aka discharging) even when the AC power is connected. This is not the complete picture, though. What /really/ happens is the following: [initial state, on-battery, AC power disconnected] battery->status == 0x01 (discharging) [connect AC adapter] battery->status == 0x02 (charging) [battery 'charge' reaches 'charge_full'] battery->status == 0x00 (full) [1 second (+/- 0.5 secs) later] batter->status == 0x01 (discharging) <-- BUG! I'm attaching `upower -d` dumps from three physical situations: * AC power connected, battery charging * AC power connected, battery full[1] * AC power disconnected, battery discharging 1. To be sure that the battery really was full, this dump was after several days of being attached to AC power.
Created attachment 39847 [details] `upower -d` when attached to AC power, and the battery is full
Created attachment 39848 [details] `upower -d` when the battery is charging
So the bug is in the kernel claiming it's discharging when the battery is actually full? Do you still have access to that hardware?
(In reply to comment #3) > So the bug is in the kernel claiming it's discharging when the battery is > actually full? > Yes, the bug is in the kernel, but perhaps upower should take into account the fact that the AC power is connected, and override that? Especially since session behaviour depends on whether the laptop is plugged in, or not. In this case, "is discharging" seems to override "is plugged in"; which would be fine if they were always mutually exclusive, but they're not (due to kernel bugs). > Do you still have access to that hardware? Unfortunately, due to a fluid-related disaster, I had to replace that laptop. I don't have it any more.
Given the impossibility to reproduce this, and the fact that the kernel is really the one that's broken, I'll close this bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.