Bug 79200

When I execute 'acpi -b' after I unplug AC, but before daemon's on-battery property changes, I see "discharging" message. But at that time UPower thinks that battery is "fully charged".

The actual problem is UPower doesn't detect when battery state changes.

I unplug AC, and then:
~> cat /sys/class/power_supply/BAT1/status 
Full
~> cat /sys/class/power_supply/BAT1/status 
Discharging
~> cat /sys/class/power_supply/BAT1/status 
Discharging

Battery state changes with slight delay, but UPower doesn't detect it.

Calling org.freedesktop.UPower.Device.Refresh through D-bus helps.

Does this still happen with 0.99.2? Pretty sure it got fixed.

(In reply to Bastien Nocera from comment #4)
> Does this still happen with 0.99.2? Pretty sure it got fixed.

Well... I added a quirk for my laptop in battery driver long time ago. I'll test kernel without the quirk when I have spare time.

The problem was that actual state change happened with a slight delay after notification is sent (buggy firmware, I think).

What changes in upower 0.99.2 could affect it?

(In reply to Alexander Mezin from comment #5)
> (In reply to Bastien Nocera from comment #4)
> > Does this still happen with 0.99.2? Pretty sure it got fixed.
> 
> Well... I added a quirk for my laptop in battery driver long time ago.

The quirk is upstream now?

> I'll
> test kernel without the quirk when I have spare time.
> 
> The problem was that actual state change happened with a slight delay after
> notification is sent (buggy firmware, I think).

If there's a slight delay, then it probably wouldn't make a difference. The code was added to update the AC state on battery removal.

> What changes in upower 0.99.2 could affect it?

In the end, none. If the quirk is upstream, that's probably good enough to consider fixed.

(In reply to Bastien Nocera from comment #6)
> The quirk is upstream now?
Yes

> If there's a slight delay, then it probably wouldn't make a difference. The
> code was added to update the AC state on battery removal.
Then I don't think anything has changed.

> In the end, none. If the quirk is upstream, that's probably good enough to
> consider fixed.
Yes, you may consider it fixed. But only for single specific laptop model.

Though it could be fixed better way in UPower. By polling with decreasing rate after notifications.

This seems to be a recurring problem with people and it would be great if upower could be fixed rather than just handling it upstream on a laptop-model specific basis - examples of this issue with others:

https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1453691

http://askubuntu.com/questions/630479/cannot-detect-power-supply-plug-unplug-on-ubuntu-14-04-2

https://bugs.launchpad.net/ubuntu/+source/upower/+bug/800339

https://bbs.archlinux.org/viewtopic.php?id=188632

(In reply to dcm-bugzilla from comment #8)
> This seems to be a recurring problem with people and it would be great if
> upower could be fixed rather than just handling it upstream on a
> laptop-model specific basis - examples of this issue with others:

But it's not a UPower bug...

(In reply to Bastien Nocera from comment #9)
> (In reply to dcm-bugzilla from comment #8)
> > This seems to be a recurring problem with people and it would be great if
> > upower could be fixed rather than just handling it upstream on a
> > laptop-model specific basis - examples of this issue with others:
> 
> But it's not a UPower bug...

It's not a UPower bug, but UPower still can solve the problem. In a generic way. Butter than kernel-side quirks.

I'd like to implement the solution in UPower, but I am not familiar with UPower's internals and Glib, so, most probably, it'll take too much time. More than I can devote to it.

I'll try to explain:
UPower can do polling of both batteries and ac adapters with dynamically changing rate. When no changes happen, interval is multiplied by 2, up to some big max_interval. When any notification arrives, interval is set to some very small value. It will do more polling than is necessary on a bug-free system, but it shouldn't hurt too much, I think.

This can solve every problem with ACPI on laptops I ever encountered.

By the way, I have same issue on my laptop, although, if I run `watch -n0,1 acpi -b` it detects battery state changes (when I pulgging AC cord in and out) pretty fine. But UPower itself doesn't.

But there is a bit strange thing: UPower doesn't totally ignore AC plug/unplugs. It detect changes only in two cases:
1) battery discarging (not a status change "charged"/"discharging", but decreasing "energy"),
2) something getting access to /sys/class/power_supply/* (aka /sys/bus/acpi/drivers/{ac/ACPI0003:00,battery/PNP0C0A:03}/power_supply/*).

I.e. if I run `watch -n0,1 cat /sys/class/power_supply/ADP1/online` and `upower -m`, and then plug/unplug AC — upower do show changes (although, yes, with some half-second lag). And if I don't run watch for /sys/class/power_supply/ADP1/online — upower doesn't print anything until battery discharges a bit.


So, as far as I'm not familiar with kernel internals, I don't understand a reason of all of that behaviour:
1) why do `watch -n0,1 cat /proc/acpi/ac_adapter/ADP1/state` detects changes in the same moment power cor is {un,}plugged?
2) why do `watch acpi -b` detects AC/battery state change (even with half-second lag) // although, I've found that /sys/class/power_supply/BAT1/status changes with the same half-second lag, and exactly in same moment when `acpi -b` changes output.
3) why do upower has much longer lag? i.e. what kind of events it is waiting for?

So, is it kernel (driver) bug or what?

P.S. I also don't see UPower in DBus (there is only PowerManagement, which is another thing).

P.P.S. Alexander, can you describe what kind of quirk that was? Maybe it shall be updated again (to work with newer laptop models)? :)

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/upower/upower/issues/22.