My batter doesn't support doing charge_full but BAT0/capacity does work (exactly the same as far as I can tell). How would you feel about me adding an option so that someone can specify the proper endpoint. Alternatively if there are only a few proper endpoints across the majority of devices it can just detect which one works.
Phew... Capacity actually reports finished battery percentage for me. But, if the battery is on ac and full reports over 100 (since my battery doesn't charge up to full capacity anymore). Can you look for docs or something showing that capacity is actually better to read from? Does your capacity report mAh or a percentage?
I verified that the /capacity does change as the battery goes down so that's a good sign. I couldn't find anything specific about whether one was better than the other though.
I went to the official docs: https://www.kernel.org/doc/Documentation/power/power_supply_class.txt
Attributes/properties detailed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ ~ ~ ~ ~ ~ ~ Charge/Energy/Capacity - how to not confuse ~ ~ ~ ~ ~ ~ ~
~ ~
~ Because both "charge" (脗碌Ah) and "energy" (脗碌Wh) represents "capacity" ~
~ of battery, this class distinguish these terms. Don't mix them! ~
~ ~
~ CHARGE_* attributes represents capacity in 脗碌Ah only. ~
~ ENERGY_* attributes represents capacity in 脗碌Wh only. ~
~ CAPACITY attribute represents capacity in *percents*, from 0 to 100. ~
~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
[...]
CAPACITY - capacity in percents.
CAPACITY_ALERT_MIN - minimum capacity alert value in percents.
CAPACITY_ALERT_MAX - maximum capacity alert value in percents.
CAPACITY_LEVEL - capacity level. This corresponds to
POWER_SUPPLY_CAPACITY_LEVEL_*.
[...]
Q: Suppose, my battery monitoring chip/firmware does not provides capacity
in percents, but provides charge_{now,full,empty}. Should I calculate
percentage capacity manually, inside the driver, and register CAPACITY
attribute? The same question about time_to_empty/time_to_full.
A: Most likely, no. This class is designed to export properties which are
directly measurable by the specific hardware available.
Inferring not available properties using some heuristics or mathematical
model is not subject of work for a battery driver. Such functionality
should be factored out, and in fact, apm_power, the driver to serve
legacy APM API on top of power supply class, uses a simple heuristic of
approximating remaining battery capacity based on its charge, current,
voltage and so on. But full-fledged battery model is likely not subject
for kernel at all, as it would require floating point calculation to deal
with things like differential equations and Kalman filters. This is
better be handled by batteryd/libbattery, yet to be written.
As we can see, we can't reliably read any values from the driver that are not present, instead we're supposed to use a system battery service if a value isn't presented by the driver directly. But, if available, we can certainly use capacity instead of my current calculation as default, and fall back to my old method if capacity isn't calculated by the driver.
We now need to decide where to take advanced values from (e.g. time remaining) or if we should calculate them ourselves.
We can do a crude estimation by calculating CHARGE_NOW / CURRENT_NOW. But that number would be very jumpy, no smoothing out or anything. A system service for time remaining would still be preferred if available.
It looks like that's how most people are solving the problem. There is a package called acpi that might be interesting, I don't know if it calculates the time remaining any better than we could though. I haven't been able to test it cause I'm at work on a Mac but I can maybe give it a try tonight.
https://www.archlinux.org/packages/community/i686/acpi/
Tried acpi, but doesn't report time remaining for me. Seems to use the same kernel interface and doesn't seem to calculate it itself
My batter doesn't support doing charge_full but BAT0/capacity does work
Likewise, for me there exists a energy_full file. Any update on this? :/
@rubdos As far as I know there hasn't been a consensus reached. I ended up just using the custom block. Not an ideal solution but it works for now.
[[block]]
block = "custom"
command = "cat /sys/class/power_supply/BAT0/capacity"
interval = 60
I'm implementing a solution, stand by :)
Not an ideal solution but it works for now.
Thanks @keeslinp, that works for now. Doesn't look great, but at least it works :-)
I'm implementing a solution, stand by :)
That's awesome. Thanks for the work on this bar; so far it's great.
@rubdos Please post the output of ls /sys/class/power_supply/BAT0 (or whatever your battery device is).
Check if it works for you now
rsmet@arch-club ~ % ls /sys/class/power_supply/BAT0
alarm cycle_count energy_full_design model_name present subsystem uevent
capacity device energy_now power serial_number technology voltage_min_design
capacity_level energy_full manufacturer power_now status type voltage_now
rsmet@arch-club ~ % ls /sys/class/power_supply/BAT1
alarm cycle_count energy_full_design model_name present subsystem uevent
capacity device energy_now power serial_number technology voltage_min_design
capacity_level energy_full manufacturer power_now status type voltage_now
rsmet@arch-club ~ %
I'll fetch master and report back.
EDIT: I have a build error in dbus. Weird.
Build error was my problem; had to -Syu base-devel. Seems like my second battery works, but my first one doesn't give a percentage (Is that because it's full?):
[[block]]
block = "battery"
interval = 10
device = 0
[[block]]
block = "battery"
interval = 10
device = 1
Yea I omitted outputting the battery percentage when full, it just shows a full battery icon in that case. So you guys think I can close this issue? What about @keeslinp ?
You have my blessing; since I got the icons to work it does make sense. Thanks again for your work.