Re: Support for multiple batteries

["Basil L. Contovounesios" <contovob@tcd.ie>]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > AFAICT only two battery status backends currently support multiple
>   > sources of information: battery-linux-sysfs and battery-linux-proc-acpi,
>   > for Linux sysfs and ACPI support, respectively.
>
> Could you clear up for me what "currently" means in this context?  I
> don't know what code was changed in January or so -- only that the
> change led to incorrect reports, on a Thinkpad T400s with two
> batteries inserted.

The battery.el package provides a user option battery-status-function
which determines how to query the system for information on its power
sources.  When battery.el is loaded, it checks for the availability of
various system features in order to set the user option to the most
sensible default out of a known set of possible values.  Each of these
values is a function (a "backend") which returns an alist of all
relevant battery information, such as load, time to discharge, etc.

Emacs 26.1[1] introduced a new possible value for
battery-status-function, namely battery-upower, which gets its
information from a UPower[2] D-Bus service (daemon) running on the
system[3].  This backend was disabled by default, i.e. in order to use
it, a user would have to manually set battery-status-function to
battery-upower.

In early February[4], the battery-upower code was improved and
battery-status-function was changed to default to battery-upower if the
system provides a UPower service.  This can be perceived as a regression
on multi-battery systems because battery-upower currently assumes a
single battery, whereas the previous defaults of battery-status-function
on modern GNU/Linux systems (battery-linux-sysfs and
battery-linux-proc-acpi) support multiple batteries.  The patch in [5]
adds support for multiple batteries to battery-upower as well, so that
it can remain the default backend when applicable.

[1]: * lisp/battery.el: Add 'battery-upower' -- very fast battery status.
05a969265c 2016-12-02 12:17:38 +0200
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=05a969265cabdf361492ed471f1a8dc369840401

[2]: https://upower.freedesktop.org/

[3]: https://www.freedesktop.org/wiki/Software/dbus/

[4]: Make 'M-x battery RET' work out-of-box for UPower users.
d8f4317f03 2020-02-06 09:13:19 -0500
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=d8f4317f03be69cfaf6a60bda228996590fd92b5

[5]: https://debbugs.gnu.org/39491#55

>   > The way they handle multiple batteries is by merging multiple data into
>   > a single report.
>
> I am not sure what that means, concretely.

The current multi-battery-aware backends, battery-linux-sysfs (which
uses the /sys/class/power_supply filesystem) and battery-linux-proc-acpi
(which uses the /proc/acpi filesystem), iterate over each battery file,
collecting and summing various relevant data, and then return them as
aggregate values.

For example, they sum the current energy and energy-when-full of each
battery, and divide the former by the latter to get the combined load
percentage.

>                       Is this what you mean by "proper" support,
>
> Proper support means at least giving a good estimate for how long
> before the machine runs out of energy, and a good estimate of the
> actual fraction of maximum charge the batteries can hold.  The code
> from last October could do that.
>
> When I type M-x battery in the version as of October 2,
> it displays something like
>
>   Power BAT, battery Discharging (98.1% load, remaining time 4:04)
>
> where the numbers depend on the energy capacity of each battery and
> the current charge of each battery, as well as the actual current or
> power.
>
> That is what I think is crucial for M-x battery.

In that case I think the patch in https://debbugs.gnu.org/39491#55 fixes
the regression you observed by making the new default backend,
battery-upower, behave like the other multi-battery-aware backends in
this regard.

BTW, the reason battery-upower makes sense as a default is because the
UPower standard provides a uniform interface[6] over various system
interfaces such as the /sys/class/power_supply filesystem, and it also
supports asynchronous battery status change notifications which can be
used by battery.el to update its mode line string without polling.

[6]: https://xkcd.com/927/

HTH,

-- 
Basil