battery-applet: Look at upower slowness/weirdness (on N900 at least)

[MerlijnWajer]

As a note, there are at least a few things to look at later:

• mAh calculation (currently based on Wh + current voltage; so that's bad) - let's see if we can get what /sys gives us
• upower is slow and inaccurate, let's figure out why (values in /sys respond fast and accurately)
• charging/discharging detection is slow/bad, again because of upower.
• TimeToEmpty and TimeToFull are often 0 or non sensical, but they are fine in /sys (again: wtf)

[MerlijnWajer]

The rx51_battery seems to contain more useful charging states in upower. Weird.

[MerlijnWajer]

Here is the upower code reading the info: https://cgit.freedesktop.org/upower/tree/src/linux/up-device-supply.c#n533 - they seem to completely ignore the time_to_* sysfs values.

Their interpretating of charging is also funny: https://cgit.freedesktop.org/upower/tree/src/linux/up-device-supply.c#n448

At least on the N900 the status seems to be 'Not charging' even when cable is not connected -- not 'Discharging'. That might explain the difference, and why UPower shows "Pending charging" all of the time. I think this also has an effect of it calculating the time-to-* values.

[MerlijnWajer]

After at least 30 minutes of discharging, the 'status' still says it's "Not charging", which apparently doesn't mean "Discharging". But the device is obviously discharding - capacity dropped 5 levels. Might be a kernel problem?

root@devuan:/sys/devices/platform/68000000.ocp/48072000.i2c/i2c-2/2-0055/power_supply/bq27200-0# cat capacity
94
root@devuan:/sys/devices/platform/68000000.ocp/48072000.i2c/i2c-2/2-0055/power_supply/bq27200-0# cat status
Not charging

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/power/supply/bq27xxx_battery.c#n1663
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/power/supply/power_supply_core.c#n307

[MerlijnWajer]

https://marc.info/?l=linux-omap&m=151869726709281&w=2

[android-808]

Is Not Charging meant for when device is connected to charger but power supplied is not sufficient to charge the device, be it supply or rate of discharge.

[MerlijnWajer]

the other way around - battery is charged and device is powered from psu not from battery, afaiu - see mail thread as well :)

[MerlijnWajer]

The charging issue is now solved with these three commits:

maemo-leste/n9xx-linux@32ae325
maemo-leste/n9xx-linux@093b8e4
maemo-leste/n9xx-linux@8c83dd8

[MerlijnWajer]

So sysfs usually updates within 5 seconds with the right value; UPower picks it up much later. But for now, I think this is OK. Since the charge detecting fixes (in kernel) it also shows the time until empty (or time until full) properly on the N900.

[MerlijnWajer]

I've just added the fully charged state to the applet -- this was missing.

[MerlijnWajer]

I think TimeToEmpty and TimeToFull work OK now that the state is fixed in the kernel. Left now is 'slowness' (maybe poll more often, or react on specific select()able events in UPower?). And the proper energy is the other thing to look at (upower doesn't report them at all it seems)

[MerlijnWajer]

I think I know why UPower updates slowly, and I've tried to explain it here: https://marc.info/?l=linux-omap&m=151977351627943&w=2

If people agree the approach is sensible, I'll write a patch to also send battery events on charging-status change.

[MerlijnWajer]

UPower not exporting the energy exposed in sysfs is something we'll have to patch in UPower, but this is lower priority for me.

[android-808]

Even on CSSU-Testing version of Fremantle there is an issue with updating charge status uniformly. Battery applet on status bar updates instantly (almost) when disconnecting charger, where as status menu widget mAh figure often only shows what it was before starting to charge for a minute or so after disconnecting.

Obviously not upower but might be worth looking at to see if it can shed some more light.

[MerlijnWajer]

I see. Well, the big problem is that udev doesn't report on the battery charging status changes. This is the first issue that needs to be fixed, I will have a patch ready soon (Compiling now).

The second issue is that the kernel detects the charging status change only after a few seconds. But this is acceptable delay to me. I've mentioned it in the email still, though.

[MerlijnWajer]

This patch is supposed to improve the situation: maemo-leste/n9xx-linux@fd09cb9

It should fix the driver not sending updates on charge status, but it doesn't fix the delay in reporting in /sys in general.

[MerlijnWajer]

I am still left wondering if it really can't detect this way faster, but perhaps the poll interval is just too high at this point.

[MerlijnWajer]

An extreme value like this makes somewhat of a difference, but it still takes a while for the chip to realise it is being charged: echo 1 > /sys/module/bq27xxx_battery/parameters/poll_interval. Maybe this is normal and fremantle kernel did something else to detect this sooner.

[freemangordon]

Could be that it is using isp1707 to detect wall chargers/USB cable

[MerlijnWajer]

Yes, those events trigger instantly. But UPower does not look at them.

[MerlijnWajer]

Moving to beta.

[MerlijnWajer]

Perhaps we can detect the 'wall charger' 'battery' in UPower and use the on-battery status:

signal time=1536608284.619499 sender=:1.17 -> destination=(null destination) serial=46785 path=/org/freedesktop/UPower; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.freedesktop.UPower"
   array [
      dict entry(
         string "OnBattery"
         variant             boolean true
      )
   ]
   array [
   ]

[spinal84]

bq27200-0 seems to be broken in the current maemo leste n900 image.
cat /sys/class/power_supply/bq27200-0/uevent

This command gives false POWER_SUPPLY_STATUS=Charging/Discharging

[MerlijnWajer]

bz27200-0 lags behind, a lot. It updates relatively slow, and upower even slower. This is why I suggested to combine the values with the usb power supply chip. Or are you saying it's wrong also after minutes of being connected?

[MerlijnWajer]

Some of this is being worked on here by @spinal84

[spinal84]

Does something from the issue remain yet?

[MerlijnWajer]

No; it's all great and smooth now. Maybe even better than fremantle. ;)