OK. Thanks for the reply.
You can even use TLP along with auto-cpufreq AS LONG as you disable TLP’s governor and turbo boost setting (along with any additional CPU-related setting you’ve set yourself in TLP but by default I think these are the only two). Then you can benefit from auto-cpufreq and TLP’s other features (USB auto-suspend, radio devices, etc.).
This just shows “No data” for Battery for me. Have you installed anything else to make it work?
Starting a thread on Linux battery with 12th gen.
- I have Ubuntu 22 mate
- with kernem 5.18
- Deactivated turboboost in BIOS
I get constant 2 GHZ on all cores at IDLE :
EDIT: Found out that powertop reports completely different values, that seems correcte.
Anyone here should read through the existing Linux battery life tuning thread first. It should have everything you need for tuning (there’s basically no difference in tuning from 11th vs 12th gen).
I also have a doc that has an extended writeup on CPU and laptop idle power usage, you can start reading here: 2022 Framework Laptop DIY Edition 12th Gen Intel Batch 1 · lhl/linuxlaptops Wiki · GitHub
thermaldto optimize your power usage behavior
turbostatto get insight on what the laptop and CPU are doing,
powerstatto make reliable averaged measurements
Found the compositor has a lot of effect on the gpu power drawn
Best for me are :
Marco without compositor
2nd is Marco builtin : xpresent
The worst is marco picom (the one I was using !)
Does anyone understand how power-profiles-daemon works? I’ve heard that it can govern the cpu and fans based on information that Framework specifies, presumably in firmware. Is this true? If so is this optimal? Also I’m wondering if someone could give me pointers on how to disable all CPU governing that TLP assumes.
From what I’ve gathered I need to change
CPU_ENERGY_PERF_POLICY_ON_(AC/BAT) to default and
SCHED_POWERSAVE_ON_BAT to 0. Everything else seems to have a default of
<none> which I assume means TLP doesn’t do anything.
PPD, which IIRC is a kde/plasma only invention, and TLP (a much more “universal” and extensible solution) do not work together at all. Devs of each have not been playing nicely with each other.
Choose one or the other. I went with TLP, and have been plenty happy with my choice.
I thought it was a GNOME invention. I’m running Fedora Silverblue so I have some inertia when it comes to disabling PPD.
Maybe it was powerdevil I was thinking of as a KDE specific deal. I really want my brain back.
Dug up a bug report about it if you feel like reading: 2028701 – tlp actively breaks power-profiles-daemon when installed
TLP lists what it’s in conflict with in their FAQ (and the section above has detailed info on power-profiles-daemon interactions): Installation — TLP 1.5 documentation
You can also add auto-cpufreq, which in their README says " Please note: auto-cpufreq aims to replace TLP in terms of functionality and after you install auto-cpufreq it’s recommended to remove TLP . If both are used for same functionality, i.e: to set CPU frequencies it’ll lead to unwanted results like overheating. Hence, only use both tools in tandem if you know what you’re doing."
Note all of them play relatively nice with
thermald, and that’s what should be loading the Framework “firmware” info - specifically, the DPTF adaptive policy tables.
Awesome, I think that is what I must have thought PPD does because I watched a talk with Framework and Fedora staff saying that there were custom fan curves.
@Jonathan_Walters and @D.H PPD is a daemon that works with both KDE and Gnome – here’s the repo.
I have a fairly in-depth understanding of it – in case you missed this, there’s some relevant/foundational info on how/what power profiles are (which set EPP values through the Intel P-State driver. EPP = Energy Performance Preference).
Long story short I forked PPD and adjusted the code – PPD IIRC simply just changes the EPP values which can be set yourself via
You can see my changes here which should result in some further understanding of what PPD does per the .patch file diffs:
I’d recommend just removing PPD altogether if you’re using TLP since it seems that PPD just changes EPP values, which TLP does via:
Also since TLP FAQs state it conflicts with PPD.
The only downside I can see is:
- having only two power profiles with TLP (AC and BAT/battery, though those exact EPP values are user customization) instead of PPD’s 3 (which are fixed and imo aren’t ideal values for power savings anyways)
- and the lack of Gnome/KDE shell integration.
So that should broadly answer your question, though I’m not sure if there’s any synergy with some Framework firmware setting. I don’t believe there are – if there were, I think it’d either be the Intel P-State driver itself and/or thermald. I could be totally wrong here, haha.
edit: just read @lhl’s comments and saw it covered some stuff I typed
Although we don’t have a Linux updater yet, we have Beta firmware for the DisplayPort Expansion Card that should improve both s0 and s0ix battery life in Linux: [Beta] DisplayPort Expansion Card firmware update to reduce system power consumption
You can run the updater using another PC if you have access to one with Windows.
It is possible to optimize the power usage of the HDMI module (at least in Ubuntu 22.04) without hawing to remove it using TLP:
The device ID of the expansion card ID should be 32ac:0002 but it can be verified with:
lsusb | grep HDMI
In /etc/tlp.conf, add the following setting:
Then restart tlp with
sudo tlp start or reboot the laptop.
In my case, in powertop, the estimated power usage of the HDMI expansion card goes down from 360 mW to 0 mW. Plugging an external display in the HDMI port still works immediately.
Side note: the keyboard backlight uses up to 1W when set to the maximum!
Though we need to see if it actually makes a difference. When I checked in powertop, it reported that the HDMI expansion card uses 10 W (!). But I don’t believe this number, it’s higher than the battery discharge rate…
Yes, the power consumption of the devices is nowhere near exact. But the drastic reduction in those values plus the fact that the battery discharge rate dropped a bit on my computer when I changed this setting (don’t remember by how much though) gives me hope that it should definitively improve the HDMI expansion power usage.
By the way, this may also help with other expansion cards (drives, SD card reader, DP and ethernet) but I only have the HDMI one at hand. The IDs of the devices can be found with
lsusb when they are plugged in.
That’s about in line with reported power savings from USB autosuspend:
TLP by default enables autosuspend mode for USB devices (
USB_AUTOSUSPEND=1 already enables autosuspend on my HDMI Expansion card, so I use that, and issue devices (like wired mice going to sleep) can be added to
I’m curious, is there a reason you’re using
USB_ALLOWLIST instead? (just the reverse of what I’m doing, or is there extra voodoo power savings from adding specifically to
Also, toggling/checking autosuspend values for a device can be easily done in powertop in the
Tunables section (changing it here doesn’t persist it after reboot):
Pressing enter on
Autosuspend for USB device HDMI Expansion Card [Framework] shows the value that’s changed, e.g.
echo 'auto' > '/sys/bus/usb/devices/3-4/power/control'
Note the value is either
on. The number e.g.
3-4 is subject to change.
- on means that the device should be resumed and autosuspend is not allowed. (Of course, system suspends are still allowed.)
- auto is the normal state in which the kernel is allowed to autosuspend and autoresume the device.
Yeah, as already stated, the line items that powertop shows are just estimates and really can’t be trusted. An accurate way to measure (IMO):
Bring the system to idle/~0% CPU and ensure the total power usage remains consistent over e.g. a minute+. Note the baseline total power usage, then do whatever change (e.g. plug in HDMI card), and then measure the total power usage afterwards. Finally, calculate the delta between the two totals. This allows a high confidence rate of pinpointing the change in power usage totals to the user change that occurred (e.g. plugging in HDMI card).
Indeed, it suffices to enable
media.ffmpeg.vaapi.enabled. Maybe the opening post should simply link to Firefox - ArchWiki , which I consider almost a canonical source for the correct settings.