In D25018#558503, @ahiemstra wrote:

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.

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.

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.

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.

In D25018#561268, @jjorge wrote:

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.

In D25018#562834, @ahiemstra wrote:

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.

@jjorge: I had to manually edit your author information into the commit, since that got lost somewhere along the way and replaced with our localization script info. I think it is OK now, but please check https://commits.kde.org/ksysguard/94f9bbc246743f5eed7eac0fc9be791f43ba5052