@lbkNhubert Thanks to the hints in this thread my laptop does now way better. Thanks a lot to all who provided helpful suggestions. The only thing I did not got working is the suspend-then-hibernate method. I did as suggested
In /etc/systemd/logind.conf I have the following relevant lines:
Thanks for the update. Early testing thus far on my end:
Note, because attaching anything is naturally a potential power draw if it fails to suspend with the laptop, this was done as a suspended laptop Framework laptop only. No applications loaded, next round will be with Chrome open and then suspended.
Ubuntu 22.10 on 12th gen, overnight lid close suspend with a 90% charge, late afternoon following day, 80% - this isn’t bad. 220.127.116.11 kernel, s2idle is deep. Wi-Fi had question mark reconnect, shows question mark, but INTERNET IS WORKING.
Ubuntu 22.04 on 12th gen, overnight lid close suspend with a 90% charge, late afternoon following day, 80% - this isn’t bad. 18.104.22.168 kernel, s2idle is deep. Wi-Fi displays normal and also connects fine.
Next will be Fedora 37 testing.
In the meantime, please feel free to open a ticket and they’ll ask you to follow a specific set of guidelines to gather specific logs. This will allow me to better see what is happening at tier 3 support.
@lbkNhubert I wasn’t not happy with the early tests, going to re-do them with matching cards as much as I have available (multiple laptops). Saw something with Fedora 37 that had me go “hmmm”, so I want to re-run this in a more consistent way.
Going to update this tomorrow after re-testing accordingly:
Pop OS 22.04, Ubuntu 22.04 and Fedora 37.
TLP on Ubuntu and Fedora, system76-power on Pop OS.
BTW, for anyone doing testing, I made an app that logs suspend/resume events into a SQLite DB and should give some more fine-grained data/does some math for normalized power drain (%/hr, %/day) that might be useful: Linux Utility to Help Track Framework Battery Usage
One useful addition to a best practices guide might be a standardized/reproducible scripts/list of tools to allow users to compare their Framework’s power efficiency w/ their specific setup (OS, modules, etc) vs your official baseline 11th/12th gen, or even other laptops.
I’m new to Framework and I’m having a problem whereby closing the lid of my Framework causes the battery to drain such that when I open it the next, the machine is completely dead. Is that related to this issue, and if so, what is the solution?
Hey Matt, did you ever get a chance to look into this? I’ve been doing some longer trips with my Framework lately and realizing my real-world battery drain is actually pretty bad for my regular usage (the past few months, I’ve only been doing plugged in/short commutes and haven’t properly run-down my battery). I used gnome-battery-bench to do some testing w/ a Firefox: 2022 Framework Laptop DIY Edition 12th Gen Intel Batch 1 · lhl/linuxlaptops Wiki · GitHub
Between batterylog and Selenium code I have lying around, I feel like it wouldn’t be so hard to have some standardized workloads - although the most interesting bits I think might be gathering data points with different setup info (platform, modules plugged in, BIOS versions, system versions, background processes, RAPL settings etc) to see the variance across setups.
Still on my list (it’s a large list). That said, one of the first things that is coming will be a guide on suspend to hibernate which is what people in Linux “should” rely on for overnight off power status. On those occasions where I am unable to suspend while connected to AC power, it’s what I use.
One big problem with hibernate is with encrypted partitions - besides setup being pretty tricky if you don’t want to jump through hoops (or if you encrypt your partitions wrong), the real killer is that unlike w/ encrypted volumes in other OS’s, after hibernation there’s AFAIK there’s no way to avoid having to do a LUKS decrypt after a hibernate on Linux. With the Framework draining on average 1-2% during suspend, you have to balance how aggressively you hibernate with how often you want to type a very long password between resumes.
(That being said, for my recent travel, suspend/hibernate wasn’t the limiting factor for my battery life situation. My Framework simply wasn’t able to last through basically any of my flights (I mean, not even half of a single trans-pacific flight) and also couldn’t handle long travel days/media offload without a lot of babying/powerbank/plug juggling. The I/O power situation is also really dire, the microSD module is basically unusable. I’ve actually thrown in the towel and picked up an M2 MBA as a travel laptop.)