Move ACPI battery information from /proc/acpi to /sys
AcceptedPublic

Authored by jjorge on Mon, Oct 28, 9:25 PM.

Details

Reviewers
davidedmundson
ahiemstra
Group Reviewers
Plasma
Summary

Since kernel 2.6.24 in 2008, the /proc/acpi/battery interface is deprecated.
There is for years no updated kernel which wouldn't provide the /sys/class/power_supply/BAT0 in a laptop
This patch removes the useless old path, and uses the sysfs to provide 3 informations :

  • current flow in mA (charge or discharge)
  • charge percent against last completed full charge
  • charge percent against battery by design charge

Ref:
https://cateee.net/lkddb/web-lkddb/ACPI_PROCFS_POWER.html
https://bbs.archlinux.org/viewtopic.php?id=97761

Diff Detail

Repository
R106 KSysguard
Branch
acpi-move-battery-to-sysfs
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 18540
Build 18558: arc lint + arc unit
jjorge created this revision.Mon, Oct 28, 9:25 PM
Restricted Application added a project: Plasma. · View Herald TranscriptMon, Oct 28, 9:25 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
jjorge requested review of this revision.Mon, Oct 28, 9:25 PM
ahiemstra requested changes to this revision.Mon, Nov 4, 2:10 PM

Hmm, I would like to see some smarter sys file handling for this. Right now, multiple calls to getSysFileValue result in the same file being read from disk over and over. While the original implementation may not have been ideal either, the update function at least made sure the ACPI stuff got only read once per update. If you need some inspiration, Memory.c has a fairly decent implementation.

This revision now requires changes to proceed.Mon, Nov 4, 2:10 PM
jjorge added a comment.Mon, Nov 4, 5:04 PM

Hmm, I would like to see some smarter sys file handling for this. Right now, multiple calls to getSysFileValue result in the same file being read from disk over and over. While the original implementation may not have been ideal either, the update function at least made sure the ACPI stuff got only read once per update. If you need some inspiration, Memory.c has a fairly decent implementation.

Are you sure this is a good idea? While previous update function readed only one file in /proc, like memory.c does, we read different files in /sys : one for each information. So this is not the same file readed over and over (and it is not read from disk as it is a virtual fs exposed by the kernel). Thanks.

jjorge requested review of this revision.Mon, Nov 4, 5:06 PM

So asking again for feedback, if I understand well how phabricator works ...

You are right, sorry. I was confusing /sys with /proc, which does have a lot of "put all of this information in a single file" stuff going on. It would still be nice if there was a better way of getting this information, but that is not related to this change. So then I mostly have style nitpicks as comment.

ksysguardd/Linux/acpi.c
70–71

Can you clean up the indentation of this function? It should use 4 spaces for indentation.

110–117

Braces on newline for function definitions please.

155

I don't see why current needs to be >0 ? What if I have an empty battery?

178–182

Braces on newline for function definitions please.

335

Using class as name here seems a bit dangerous to me, if this code ever gets compiled with a C++ compiler it will trip over this name. Maybe use className instead?

339

Please add a space between , and class

jjorge updated this revision to Diff 69357.Wed, Nov 6, 5:43 PM
jjorge marked 6 inline comments as done.
  • hopefully correct all problems found in nice ahiemstra's revision
  • - indentation corrected to 4 chars
  • - function braces in newline
  • - We can calculate charge even if current is <= zero.
ahiemstra accepted this revision.Mon, Nov 11, 11:11 AM

So, with this my system lists battery in ksysguard again, which is really nice. I do wonder about the usefulness of the "DesignCharge" sensor and would maybe like to see some additional sensors, but those can be discussed in a follow up.

This revision is now accepted and ready to land.Mon, Nov 11, 11:11 AM

Thanks. Just some thoughts : designcharge is usefull if you want to see the percentage of charge you reach against what it should be with a new battery. For some adicional sensors, of course, even if I dont see what ones you are thinking about.

alexde added a subscriber: alexde.Mon, Nov 11, 6:38 PM
alexde added inline comments.
ksysguardd/Linux/acpi.c
129

Are states > 100 or < 0 really well defined? Is it save to assume that a state > 100 can be associated with 100?

161

Are states > 100 or < 0 really well defined? Is it save to assume that a state > 100 can be associated with 100 for example?

plugins/process/nvidia/nvidia.json
12

This should maybe be a part of a separate patch as it seems unrelated.

jjorge marked an inline comment as done.Mon, Nov 11, 7:24 PM

Are states > 100 or < 0 really well defined? Is it save to assume that a state > 100 can be associated with 100?

Yes : this is a percentage. States out of this value are bad hardware : I have a travel battery which shows crazy values along time, from 0,001Wh capacity till 901Wh (Real capacity is near 45Wh).

This should maybe be a part of a separate patch as it seems unrelated.

You're right, this is already in master, I have badly also selected this commit in my patch.

alexde added a comment.EditedMon, Nov 11, 7:56 PM

Are states > 100 or < 0 really well defined? Is it save to assume that a state > 100 can be associated with 100?

Yes : this is a percentage. States out of this value are bad hardware : I have a travel battery which shows crazy values along time, from 0,001Wh capacity till 901Wh (Real capacity is near 45Wh).

How can you interpret these weird charge_now values correctly? If the range is [1/1000, 901] Wh, while the real range is [0, 45] Wh, how does the charge curve look like while charging or discharging?
Are there (continues) values in [46, 901] Wh? Do you assume all of those as 100%?

Edit: Is the charge_now or the maximum value incorrect due a faulty battery?
Sorry, I just want to understand it. :)

How can you interpret these weird charge_now values correctly? If the range is [1/1000, 901] Wh, while the real range is [0, 45] Wh, how does the charge curve look like while charging or discharging? Are there (continues) values in [46, 901] Wh? Do you assume all of those as 100%?

The only correct interpretation is that a battery chan't have 2000% charge, neither -45%. So we assume the 0-100 range for a percentage ;-)

Edit: Is the charge_now or the maximum value incorrect due a faulty battery?

Yes, that's the reason. The BIOS tells me I should junk it, but I can still work nearly two hours more when it is plugged in ;-)

How will this be merged? Will it be in time for Kde 19.12 ?

KSysGuard is part of Plasma, so these changes will not be released until the next plasma release, which is 5.18 and should be released I think January next year.

Do you have a developer account to push the changes? Otherwise I can do that for you.

Do you have a developer account to push the changes? Otherwise I can do that for you.

I don't, so yes please do the push.