Bug: Battery graph and last full charge is not shown

[likeadragonmaid]

• Device: Mi A2
• Channel: devel
• Build: 2022-09-05

Steps to reproduce

1. Launch system settings app
2. Tap on battery icon under system section

Expected behavior

Battery graph should be visible along with Last full charge.

Actual behavior

Battery graph isn't drawn and Last full charge shows up as N/A.

[niaproxy]

Hi @gibcheesepuffs !

I encounter this issue on Poco X3 NFC in dev branch. Quick digging in source code here and here pointing at upower daemon.

For some reason daemon don't collect battery level history - maybe something wrong with permissions?

[Flohack74]

No the daemon is alright, the display is wrong, you see the graph of a fake battery reported by kernel.

Modern Android kernel sreport 4 or 5 batteries and BMS systems to upowerd, and Ubuntu Touch guesses which is the right one, since there is no good indication what it could be. Guessing worked until Halium 7.1 but then it got really hit or miss.

[niaproxy]

Hi @Flohack74 !

The daemon indeed works as intended, furthermore it collects and displays all the data! upower -e shows a lot of devices - one that works is "battery_battery"

phablet@ubuntu-phablet:~$ upower -e /org/freedesktop/UPower/devices/line_power_bq2597x_standalone /org/freedesktop/UPower/devices/battery_battery /org/freedesktop/UPower/devices/line_power_dc /org/freedesktop/UPower/devices/line_power_main /org/freedesktop/UPower/devices/line_power_pc_port /org/freedesktop/UPower/devices/line_power_usb /org/freedesktop/UPower/devices/line_power_bms /org/freedesktop/UPower/devices/battery_batt_verify /org/freedesktop/UPower/devices/DisplayDevice

Then i ask "battery_battery" about history and statistics via Dbus it report back: dbus-send --print-reply --system --dest=org.freedesktop.UPower /org/freedesktop/UPower/devices/battery_battery org.freedesktop.UPower.Device.GetHistory string:charge uint32:0 uint32:100

method return time=1663493286.067300 sender=:1.113 -> destination=:1.137 serial=141 reply_serial=2 array [ struct { uint32 1662888833 double 89 uint32 0 } struct { uint32 1662892151 double 87.5 uint32 2 } etc...

One device that confuse me is "DisplayDevice" it return only percentage and charge state - exactly what we see in settings.

In merge-requests i found your patch - i think it will fix issue when merged.

Edit: Or add another check aganst if (kind == UP_DEVICE_KIND_BATTERY) like if (type == UP_DEVICE_TECHNOLOGY_LITHIUM_POLYMER) because in upower -d list 3 devices reports as battery and only one has tech type.

[niaproxy]

Created a merge request on gitlab

[Flohack74]

@niaproxy I do not think its that easy :) becasue we have to make a consistent solution: Battery is used by repowerd, by system settings, by indicator-power and also by Bluez to display the battery level in e.g. a car.

We are discussing this since a long time, but Canonicals implementation was not bad and has some real good point, ultimately though we need a central place where all those consumers can get the real battery.

It must also be configurable for the porter so that for any device it can be overridden properly. And last but not least it must also work on a mainline desktop in the future which is because Lomiri goes into debian repos ;)

Cc: @maciek134

[Flohack74]

I mean @maciek134 we can merge this MR as a bandaid ofc.

[maciek134]

It follows similar thinking to my indicator-power bandaid ;p This will break stuff like showing peripherals battery status and UPS on desktops, but I'm not sure these work now?

It will definitely be easier to revert there once we do it properly than to hunt down every port that disabled batteries in the kernel (some of which contain some useful stuff).

[niaproxy]

This will break stuff like showing peripherals battery status

It broken in mainline Ubuntu 22.04 too :3

it must also work on a mainline desktop

Whoa - i completely miss that! Will soon try lomiri on my touchscreen notebook)