It doesn’t usually work that well in practice. I have been running an M1 MBA for the last couple years (asahi Arch and now Asahi Fedora spin). More complex pieces of software typically have build system and dependencies that are not compatible or just make hunting everything down a hassle.
That said there is a ton of software that is available for arm64 on Linux so it’s really not that bad of an experience. And there are usually alternatives available for software that cannot be found.
The charge controller’s idea of what’s going on is totally independent of what’s going on in the CPU. It doesn’t know and doesn’t care about your OS.
Multiple calibration cycles are pointless. Doing it once (every few months) should be enough. Or doing it never is fine too. I had one laptop (thinkpad l480) that would get out of calibration, such that the charge controller would go straight from 45% charge to 1%.
What’s happening is that lithium batteries have a very steady voltage for most of their usage. The voltage mostly changes at the top and bottom ~%10 of charge. Everything else in the middle is guesswork - the charge controller has to measure and count every drop of current going in and out of the battery. Measuring consists of a current meter - you put a very low value resistor in line and measure microvolts of drop across it. You can have a high precision current meter, or you can have one that “doesn’t burn a lot of power in the dropper resistor”, not both. Some systems have too inaccurate a meter. Some have phantom draws that aren’t well accounted for (like the battery’s own internal resistance and drain). If the battery spends all of its time in the “voltage never changes” region, the current counter’s guess will diverge from reality.
When you discharge/recharge the battery, you are forcing its current counter to realign itself with reality. Whatever it thinks is left in the battery, nope that’s really zero when we drop to ~3.2 volts.
It’s not true that precision measurements are impossible with low value resistors, a lot of measurement equipment works exactly like that - it might just be more expensive than what the manufacturer is willing to budget for.
Even if they’re marketing BS, some decent mainline support for Qualcomm chips is always welcome. It’ll help projects like postmarketOS and mobile Linux distros massively to have more usable Qualcomm code.
Chrome being worse than Firefox doesn’t make Firefox’s default telemetry, adware, and DoH to cloudflare good. When the bar is Chrome, essentially any browser passes.
Telemetry you can’t easily disable (requires modifying about:config, can change on update), Glean (nastier than anything in chrome), DoH to cloudflare, pocket (adware), Anonym.
There’s two things you might be talking about here:
The old way of making sure nickel cadmium batteries didn’t degrade, which was to discharge them all the way and charge them back up all the way. Your new laptop is almost certainly using lithium ion batteries which are chemically “damaged” more through that process than just leaving them plugged up all the time.
You could be talking about the old way of dealing with charge controllers, where the controller relied on the bios or os to tell it what to do and didn’t “know” how to respond to batteries at different stages of charge. This hasn’t been the situation for like fifteen years. Nowadays charge controllers go “yup, ready to go boss, 12345mah of charge, 90%” when some bios or os polls them.
You don’t even need to manually keep your battery in the 20-80 range nowadays since almost every charge controller automatically monitors temperature and adjusts charging parameters to not damage the battery. It’s not like the old days where the charge controller was just an ic controlling a fet acting as a slucegate between the battery and the power brick.
Heck, lithium ion batteries nowadays last longest the longer they’re plugged in. Running them to <10% every charge cycle actually diminishes battery life!
You don’t even need to manually keep your battery in the 20-80 range nowadays since almost every charge controller automatically monitors temperature and adjusts charging parameters to not damage the battery.
Sort of. The charge controller will limit charging current if too far outside normal temperature ranges. But it will still charge all the way to 100% unless you manually limit that with the settings on your device.
Heck, lithium ion batteries nowadays last longest the longer they’re plugged in.
That’s actually incorrect, charging a Li-ion battery to 100% is significantly worse for it than charging to 80%, and keeping it at 100% plugged in is even worse. Which is why most devices will have the option to stop charging at 80% or near there instead of going all the way to 100%.
Charging while warm is also much worse than charging below 50 degrees F or so.
While you’re right that going all the way up to the 4.2v that the battery is rated for is worse than if it just stayed at 4v, by not discharging to half or more you’re reducing the charge cycles which directly correlates to longer life.
Ultimately in lieu of a charge controller or os that does that for you, the easiest way for a user to extend battery life without going psycho mode is to charge they phone, eat hot chip and lie.
I know all the macs and iphones have that predictive charging thing where if you’re always leaving your phone or computer or phone plugged in overnight they’ll keep it around 80% or so till about an hour before you wake up and charge the rest of the way then.
Windows computers have something called smart charging but I don’t have any experience with it.
Theres a bunch of different ways to control charging in Linux.
It really seems like this is a solved problem and I’m glad to not be worrying about plugging and unplugging my phone to maximize my battery life.
Afaik in almost all cases the battery monitors work independently of the OS (on the BIOS level I guess) so you should only do the calibration if you notice issues with the monitoring and not more often than like once a year. Also if the battery is very worn out, there’s no way to get accurate measures.
Battery calibration is supposed to help the battery’s firmware figure out how low the battery can go. It also tends to hurt your battery, so you should avoid performing these calibrations and keep the charge between 20% and 80% as much as you can.
It seems what you’re trying to do is improve battery estimation by the OS on a new machine. And in that case, Is just trey trip love* I’d just try to live with possible insecurity of not knowing whether the machine has 15 or 25 minutes left.
What render settings are you using? Kdenlive doesn’t use Movit for rendering but rather Melt. You can try AMD VAAPI under Hardware Accelerated in the Render menu. Some other tweaks you can do include enabling Parallel Processing (for your CPU, it can go up to 8), changing Custom Quality, and changing Encoder Speed (though the last two options do affect quality so experiment with what works for you)
Maybe you are just dealing with the new Plasma 6.1 feature for multi-monitor setups? It’s pretty useful, but I find it annoying too, and thankfully this is KDE, so there’s always the possibility to make it your way.
I’m referring to the issue outlined here. Thanks for the link to that problem, I haven’t encountered it yet but I haven’t played with Wayland/KDE6 all too much yet
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.