It's ACPI - most laptops ship with half-broken ACPI tables, and provide support for tunables through windows drivers. It's convenient for laptop manufacturers, because Microsoft makes it very easy to update drivers via windows update, and small issues with sleep, performance, etc. can be mostly patched through a driver update.
Linux OTOH can only use the information it has from ACPI to accomplish things like CPU power states, etc. So you end up with issues like "the fans stop working after my laptop wakes from sleep" because of a broken ACPI implementation.
There are a couple of laptops with excellent battery life under linux though, and if you can find a lunar lake laptop with iGPU and IPS screen, you can idle around 3-4W and easily get 12+ hours of battery.
LG Gram user here with Debian as a daily driver. Can confirm, maybe not 15h, but I don't think about charging. Plus, it's super stable, not a single crash or hang-up over years. It just works. I hope LG will keep this up and not mess up next iterations of the hardware.
I had an LG gram before the battery in it gave out and now it won't boot with the battery plugged in. The battery life was amazing, it always slept properly, etc.
Now I have a Framework. It randomly reboots when I close the lid, the battery life is terrible, etc. I live with it since I like the idea of a repairable laptop.
What's standing in the way of doing something like NDISwrapper but for ACPI? Just that nobody with ghe required skills has spent the effort? Or something technical?
If the observable behavior is bad Linux performance, it's a Linux problem.
There's a saying in motorcycling: it's better to be alive than right. There's no upside in being correct if it leaves you worse off.
There are ways to make things better leveraging the Linux way. Make more usable tools for fixing ACPI deficiencies with hotloadable patches, ways of validating or verifying the patches for safety, ways of sharing and downloading them, and building a community around it.
Moaning that manufacturers only pay attention to where their profits come from is not a strategy at all.
Decompile your ACPI tables and then do a grep for "Linux". You are likely to find it, meaning the vendor took time to think about Linux on their hardware. Some vendors take the time to write good settings and code for the Linux ACPI paths, some dump you into no-man's land on purpose if your OSI vendor string is "Linux".
It's quite literally a vendor problem created by vendors leading anyone that doesn't run Windows astray in some cases.
If you run Linux, then dare to change your OSI vendor string to "Windows", you've entered into bespoke code land that follows different non-standard implementations for every SKU, where it's coded to work with a unique set of hardware and bespoke drivers/firmware on Windows. You also forgo any Linux forethought and optimizations that went into the "Linux" code paths.
My point is that from the Linux side, you're damned if you and damned if you don't no matter how you tackle the issue. If the layer above Linux is going to deliberately malfunction and lie on the Linux happy path, or speak some non-standard per-device driver protocol if you lie to use the Windows path, there's not much that can be done.
It's only a "Linux problem" if you're trying to run Linux on hardware that is actively hostile to it. There are plenty of vendors who supply good Linux happy paths in their firmware, using their hardware is the solution to that self-imposed problem.
I think the correct strategy in this case is to return your laptop to the store if it has linux compatibility issues, and keep trying until you find one that works.
i.e. don't support vendors whose laptops don't work in Linux.
> Does anyone know why Linux laptop battery life is so bad?
It's extremely dependent on the hardware and driver quality. On ARM and contemporary x86 that's even more true, because (among other things) laptops suspend individual devices ("suspend-to-idle" or "S0ix" or "Modern Standby"), and any one device failing to suspend properly has a disproportionate impact.
That said, to a first approximation, this is a case where different people have wildly different experiences, and people who buy high-end well-supported hardware experience a completely different world than people who install Linux on whatever random hardware they have. For instance, Linux on a ThinkPad has excellent battery life, sometimes exceeding Windows.
Newer laptops come with extra power peripherals and sensors. Some of them are in ACPI tables, some are not. Most of them are proprietary ASICs (or custom chips, nuvoton produces quite a bit of those). Linux kernel or the userspace has poor support for those. Kernel PCIe drivers require some tuning. USB stack is kind of shaky and power management features are often turned off since they get unstable as hell.
If you have a dGPU, Linux implementation of the power management or offloading actually consumes more power than Windows due to bad architectural design. Here is a talk from XDC2025 that plans to fix some of the issues: https://indico.freedesktop.org/event/10/contributions/425/
Desktop usage is a third class citizen under Linux (servers first, embedded a distant second). Phones have good battery life since SoC and ODM engineers spend months to tune them and they have first party proprietary drivers. None of the laptop ODMs do such work to support Linux. Even their Windows tooling is arcane.
Unless the users get drivers all the minute PMICs and sensors, you'll never get the battery life you can get from a clean Windows install with all the drivers. MS and especially OEMs shoot themselves in the foot by filling the base OS with so much bloat that Linux actually ends up looking better compared to stock OEM installs.
In addition to the other comments, its worth noting macOS started adding developer documentation around energy efficiency, quality of service prioritization, etc. (along with support within its OS) around 2015-2016 when the first fanless usb-c macbook came out: https://developer.apple.com/library/archive/documentation/Pe...
Think I'm arguing its both things where the OS itself can optimize things for battery life along with instilling awareness and API support for it so developers can consider it too.
On top of this, they started encouraging adoption of multithreading and polished up the APIs to make doing so easier even in the early days of OS X, since they were selling PPC G4/G5 towers with dual and eventually quad CPUs.
This meant that by the time they started pushing devs to pay attention to QoS and such, good Mac apps had already been thoroughly multithreaded for years, making it relatively easy to toss things onto lower priority queues.
As an Apple Watch user for over 7 years, I find this focus on heavy app to be completely stupid.
The "smart" part of the watch is mostly useless, I've learned to use it the least possible. It is just rarely worth it to fiddle with such a restricted interface when you have the phone nearby the vast majority of the time.
The health stuff is really the killer app and they should have pivoted to low power high efficiency use case a long time ago.
It doesn't make sense to charge the watch everyday for the little utility it provides.
My Dell XPS had pretty good battery life on linux. Probably better than on windows. But Dell sells the XPS wiht linux preinstalled. So I assume it has a lot to do with the drivers. Many notebooks have custom chips inside or some weird bios that works together with a windows program. I'd say laptops are more diverse than desktop PCs with of the shelve hardware.
Yeah, my 3-ish year old 13.4" XPS Plus is currently consuming 3.9 W with around 150 open tabs across four Firefox windows, 3 active Electron apps, Libreoffice Writer & Impress, a text editor, and a couple of terminals.
That's in an extremely vanilla Debian stable install, running in the default "Balanced" power mode, without any power-related tuning or configuration.
That compares reasonably well with my 14" M3 Macbook Pro, which seems to be drawing around 3.5 W with a similar set of apps open.
Sure, the XPS is flattered in this comparison because it has a slightly smaller screen, but even accounting for that it would still be... fine? Easily enough to get through a full day of use, which is all I care about.
There's nothing special about this XPS, and I'd expect the Thinkpad models that have explicit Linux support to be equally fine. The key point is that the vendor has put some amount of care and attention into producing a supportable system.
Install powertop, the "tunables" tab has a list of system power saving settings you can toggle through the UI. I've seen them make a pretty big difference, but YMMV of course.
It mostly just breaks things unfortunately. You can faff around for ages trying to figure out which devices work and which don’t but you end up with not much to show for it.
I ran into this problem on a Slimbook some years ago now. I found that my battery drained way too fast in standby, and I remember determining that this was some (relatively common) problem with sleep states, that some linux machines couldn't really enter/stay in a deeper sleep state, so my Slimbook's standby wasn't much of a standby at all.
A lot of people say that lightweight desktops/distros help. Probably GNOME/KDE unnecessarily use your SSD, network, GPU and other resources even when you are idle, compared to using a minimal WM and only starting the daemons you actually need.
I personally never tested it, and I can't find definite benchmarks that confirm and measure the waste.
While each of the comments here describe individual failings, on a well supported laptop it is possible to get better power efficiency than windows if your willing to spend the time manually tuning linux, the powertop/etc suggestions are fine, but fundamentally the reason some of the 'lighter' DE's save so much power is that there is a lot of 'slop' in the default KDE/GNOME and application set. You have random things waking up to regularly and polling stuff which pulls the cores out of deep sleep states. And then there are all the kernel issues with being unable to identify and prioritize/schedule for a desktop. Ex: the only thing that should be given free reign is an active forground application, grouping and suppressing background applications, running them on little cores at slow rates if they have work to do/etc. All that is a huge part of why macos does so well vs linux on the same hardware.
The comment about ACPI being the problem is slightly off base, since its a huge part of the solution to good power management on modern hardware. There isn't another specification that allows the kind of background fine grained power tuning of random busses/devices/etc by tiny management cores who's entire purpose is monitoring activity and making adjustments required of modern machines. If one goes the DT route as QC has done here, each machine needs a huge pile of custom mailbox interface drivers upstreamed into the kernel customized for every device and hardware update/change. They get away with this in the android space because each device is literally a customized OS and they don't have the upstream turnaround problem because they don't upstream any of it, but that won't scale for general purpose compute as the parent article talks about.
