* Add support for batteries outputting Time to empty on linux
The battery in the pinebook pro does not output the remaining charge
in Wh or mAh, so i3 cannot calculate the time remaining. However, it
does directly output the number of minutes remaining on in
POWER_SUPPLY_TIME_TO_EMPTY. This adds support for reading this field
and converting it to seconds_remaining.
* Add testcase for POWER_SUPPLY_TIME_TO_EMTY_NOW
its now possible to have percentage before and after a variable. except
for the date. But percentage with dates does not make much sense to me, so
i skipped it.
Calling globfree(NULL) is undefined behaviour. In Linux (glibc), it
results in a segmentation fault.
It is also undefined behaviour to call globfree(&pglob) if a previous
call to glob(&pglob) returned an error.
Signed-off-by: Olivier Gayot <olivier.gayot@sigexec.com>
`print_battery_info` computes `batt_info.percentage_remaining` by
dividing batt_info.remaining by `full`. If `full` is `0` then the
battery remaining will be reported as "inf".
Before this, it tries to set `full` to either the design capacity or to
the last known good charge. It determines if these values are available
by checking whether their fields in `batt_info` are non-negative. As it
initialized `batt_info` with values of `-1`, a non-negative value
implies that something has provided a value.
`slurp_all_batteries` and `add_battery_info` however initialize these
fields to zero, so if these functions are called then
`batt_info.full_design` will always be used.
This means that on systems that don't provide a value for design
capacity the percentage remaining will be reported as "inf", unless the
user has set `last_full_capacity` to `true` in their `i3status.conf`.
This patch changes `print_battery_info` to expect values for the battery
capacity to be strictly greater than zero. This seems reasonable as a
battery with a capacity of zero isn't useful.
An alternative solution would be to change `slurp_all_batteries` and
`add_battery_info` to initialize `batt_info` with `-1`, as
`print_battery_info` does. This is less appealing as `add_battery_info`
is accumulating the values, so using `-1` would introduce off-by-one
errors without additional code to avoid them.
Using title number all, this enables aggregates. Note that FreeBSD and
OpenBSD previously only reported aggregates, so this is bringing Linux
and NetBSD that functionality.
Changes the default battery reporting to the aggregate since most
users probably don't care about individual batteries. For single-battery
systems there should be no change.
Fixes one obvious memory leak in NetBSD.
This allows OSes that support reporting multiple batteries to simply
sum into full_design,full_last,remaining and let print_battery_info
make computations.
Doing strlen(a) == strlen(b) && strncmp(a, b, N) seems to have no
benefits compared to just strcmp(a, b). The NetBSD cstring properties
come from the kernel, not the user.
The test for units did a prefix match, but that looked like a bug, the
unit is "Watt hour" in my Virtual box.
This changes the behavior for NetBSD: previously this time was not
shown while charging. On Linux it was treated as "full time". This
change makes all OSes behave the same.
OpenBSD and FreeBSD did not support emptytime previously.
The hw.acpi.battery.state sysctl returns a bitmask of flags as
defined in <dev/acpica/acpiio.h>. Use constants from this header
to examine the state and check for the charging flag to determine
if the battery is charging.
The boolean flag 'watt_as_unit' may be used without being initialized if the
configured battery path does not contain expected statistics (for example if
it is misconfigured and points to AC adapter info or simply an unrelated file).
Even though it does not cause ill effects, it causes a warning (true positive)
when running i3status under Valgrind. Initialize the variable to make code
well-defined.
Replaced hard coded status strings (CHR, BAT, FULL) in
print_battery_info.c with user defined strings. The new strings are
'status_chr', 'status_bat' and 'status_full' and can be set in i3status.conf.
e.g.
status_chr = "⚡ CHR"
If any of the new status strings is omitted the standard strings (CHR,
BAT, FULL) are used.
In my case, the voltage variable would stay initialized as -1,
which caused the calculation of battery charge percentage to be
incorrect (I would get the message that there is no battery present
or even -0% charge).
I have no idea how this would affect other systems, since I don't
have a chance to test this.