But i’d like it to be exactly 60.0 percent, my friend. Simply because it is my fourth favorite number, you know..
I am sick and tired of people telling me, “nah, you didn’t need that anyway”, when things don’t go as they should.
I can switch to apple for that, and have working firmware as a compensation for enduring the fanboys.
We are aware of an issue introduced in 3.07 where if the battery charge limit is set below 100%, the battery may charge up to 100%. We are prioritizing a fix for this coming to be released to stable before the end of March.
I gave you a reasonable advice, you can take it or ignore it, it’s up to you. But it is not neccessary to get rude.
The only “rude” thing here is to somehow assume to be in a position to tell other people what is “reasonable” and what is not.
@Bernd_Steinzimmer
Except that when you go into the BIOS to set the charge limit, the help text next to it suggests 60%
As I said, I gave you an advice, I did not dictate or forced you to do so.
I would question that help text, how meaningful it is, to give up almost half of the battery power you have paid for.
you can do that, of course. But rest assured, that Framework, or at least i, arrived at that number very carefully.
Thanks a lot for the update, @Kieran_Levin!
Do you have AMD-SB-7033 (CVE-2024-36348/CVE-2024-56161) on your radar as well? The microcode tempering instructions and tools are now widely available, so it would be really great to see this patched.
Well, that sounds good. However, and frankly:
(EDITED to fix a misspelling.)
Oops. Yes I did. I will correct it now.
Really before the end of March?
I guess so. IIRC 3.06 had problem with battery extender, 3.07 has problem with charge limit. If they can somehow combine 3.06 and 3.07… you know.
or revert back to 3.06 and remove the battery extender feature.
It is now…
Experienced the charge limit bug after updating from 3.06 BETA → 3.07 STABLE.
Prior to the update, charge limit was set to 80% and battery extender was disabled.
Charge limit works again after setting the limit to 75% for now.
Some charge limit levels working and not others sounds like charging doesn’t get stopped if the EC doesn’t measure the exact charge level it wants, like the level jumping from 59% to 61% in one measurement interval. Might even be different for each individual battery and charge cycle.
I see the update is on LVFS, but it has not showed up yet on KDE Discover, any idea why?
Jnathan_Haas wrote:
[. .] many Linux distributions suggest to automatically install LFS firmware updates [. . .]
Luckily - given that I do not want to install this broken update - my Linux distribution (viz., Linux Mint) does not do that.
I can neither stand or understand the insatiable desire of pushing firmware updates.
The mere suggestion of automatically install LFS firmware updates is a red flag in my opinion.
Pushing or automating BIOS update, especially un-downgrade-able BIOS, opens up a loophole for abuse. A while ago a colleague of mine has a HP laptop with Linux(for productivity)/Windows(for gaming) dual boot. He always set and use S3(suspend-to-RAM) on Linux. Unfortunately HP had a BIOS “upgrade” pushed by Microsoft Windows update automatically, which permanently disabled S3 on firmware level and the [deep] option on Linux is gone. To make matters worse, the “upgrade” is not reversible.
It’s Microsoft, Linux distributions must not follow down the same dystopian road.
OS updates should NOT include BIOS firmware update by default. It should always be opt-in
I disagree, many users do not go out of their way to read the patch notes/change lot of BIOS updates and even fewer will go out of their way to look for said updates
Yes, automatic updates should not remove functionality or introduce regressions, we can agree on that. Removing the ability/ease of access of BIOS updates is not the answer. That just means more users will be insecure, hardly an ideal scenario I think you would agree.
