Hi Sebastian!
On Fri, 25 Feb 2022, Sebastian Reichel wrote:
On Thu, Feb 24, 2022 at 10:53:32AM -0600, Carl Edquist wrote:
I am happy to put in the legwork to get wmpower working using whatever
the blessed replacement is for the acpi procfs power stuff. Maybe you
can help shed some light on the sysfs interface for me.
FWIW the power-supply sysfs API exists since quite some time now
(4a11b59d8283 from 2007), so it's not particularly new ;)
Sure, although .. it is new to me. (I did not have a reason to care
before this month! :) And I was having trouble finding any documentation
on certain details... So your help is appreciated!
... the power-supply subsystem passes through the data provided by the
hardware without unit conversion. So one of the battery fuel gauges in
your laptops provides its numbers in Wh and one provides it in Ah. In
(non ACPI) embedded systems you might also get neither of them.
Again I seem to be losing my mind, since now both of my laptops show
energy_now & power_now. Is it possibly that a single battery might
sometimes come up showing Wh and sometimes Ah ?
The units for the sysfs files are fixed, so a system reporting Ah
provides current_now/charge_now files and Wh based systems provide
power_now/energy_now files.
Ok, so if I understand you right, if the /proc/acpi/battery/BATX/state
shows "present rate" and "remaining capacity", then I should always be
able to find the sysfs equivalents for that battery under
current_now/charge_now or power_now/energy_now.
I guess the convenient thing about the /proc/acpi/battery interfaces is
that it automatically presents the right info for rate & capacity.
By the way, what I meant here is that it was handy in the procfs interface
to be able to look up a single value (eg "remaining capacity"), and that
always provide you with the number you cared about, rather than have to
try looking up two separate values (charge_now or energy_now) to see which
one exists. As far as I can tell there is nothing in the sysfs equivalent
even telling you which attribute to check, other than trying both and
failing over as necessary. (Eg, there is not something like a
"capacity_type" attribute to tell you whether a battery reports "energy"
or "charge" ...)
The files in /sys/class/power_supply always report almost all values in
µ units (i.e. µA, µV, µAh, µW, ...), one value per file and with fixed
units. Documentation can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-class-power
I kind of found the documentation there lacking, from an end user
perspective. For one, it does not seem to mention anywhere the existence
of the power_now/energy_now files, so it was only by chance that I
happened to stumble on their existence on one of my laptops. For another
thing, not all the attributes in that document necessarily appear to be
present. Eg, "current_avg" does not appear for my battery when
current_now does. (Nor "power_avg", which is not documented, but
presumably should exist as a "current_avg" analog when power_now is
present?)
Anyway point being it really was not clear from the outside which
attributes are reliably available, and thus what the general method is for
something as simple as determining time-to-empty and time-to-full for
batteries. (To replace what used to work in /proc/acpi/battery, that is.)
I'm also curious, is the "BAT[0-*]" pattern for battery names
consistent, or are there other possibilities? [...]
The subsystem does not have any name constraints. But you can find the
device type via the 'type' file and non-system level devices (e.g.
battery of a game controller) set the 'scope' property to "Device".
Oh wow. I hadn't thought of game controller batteries. I have no idea
what it means to set the 'scope' property though :)
I'm also thinking to enumerate batteries & AC power supplies via
/sys/bus/acpi/drivers/{ac,battery} rather than /sys/class/power_supply,
as surprisingly even a USB-C stick can show up under power_supply, and
it's not obvious if there's a clean way to sort out what's what then.
USB-C is kind of tricky with the option to reverse power-flow in many
cases (e.g. laptop can charge a power bank or power bank can charge a
laptop using the same connector). In general you definetly can get
non-ACPI power-supply devices, e.g. batteries from wireless keyboards.
That is wild (interesting!), but I think in this case I'm only interested
in the main battery sources.
Also some devices have broken ACPI battery handling, so the ACPI driver
is blacklisted and native hardware drivers are used instead. In that
case you will not find anything power related in /sys/bus/acpi.
Ok. So I think as long as it was something that used to report under
/proc/acpi/battery (which I think is the scope I care about here), it
should report under /sys/bus/acpi/drivers/battery, right?
Thanks for all the help!
Carl
