Was there a difference when setting the udev rule directly?
I have no negatives to report from that setting (which I also used on 11th gen Intel).
@nadb thanks for going down that rabbit hole, and that’s essentially how I operate as well. However, curiosity struck me (argh!) and apparently TuneD allows edit: will allow? custom profiles:
include a number of predefined profiles for common use cases…and it is possible to fully customize them
So TuneD would essentially be TLP with the extra ability to create as many profiles instead of just 2 (AC/BAT), minus its battery care/management ability (which doesn’t seem in line with TuneD’s goal) – as far as I looked for now.
That solves my main issue with PPD, and my main issue with TLP’s only-2-profiles. Framework could test/share (like with TLP) as many custom TuneD profiles as needed. For example, extreme power saver (e.g. just reading documents), power saver, balanced, performance without turbo, performance with turbo (e.g. sacrificing battery to finish compiling/rendering as quickly as possible), etc. This would also go hand in hand with the upcoming Framework 16’s numerous configs, e.g. one profile for a specific discrete GPU may not be ideal for another. Exciting, imo
Battery management is the other missing feature but only tangentially related to this.
Cool. For me all those choices could only possibly be made manually, and I simply don’t want to have to that. Everytime I have tried out other options and have to build the habit to turn on and off battery profile it has not gone well. TLP does this automatically and if you need profiles it is simple enoough to write multiple configs and have a script stop the service and rotate in the new config (profile) and restart the service all while keeping the most important part of the automation whether you are on AC or on BATTERY integral to the service.
Yeah it’s one extra thing to keep track of, so basically I only bother switching on battery to a more performant profile when I need quicker performance and then switch back immediately when the job is done. That way I remember, job started, switched to higher energy profile. Job finished, switch profile back. Easy peasy lemon squeezy
It’s infrequent though and context dependent on a lot of external factors like if I need to catch transportation sooner rather than later.
I also tend to always default to some power savings profile on battery (e.g. automatically set when resuming from suspend while on battery). That way, I don’t unnecessarily lose battery when I need it, and if I notice things are a bit too slow, swap profiles temporarily for the task at hand.
Oh hey, thanks for the idea! And saving me from going down the TuneD rabbit hole, for now, lol. I already use scripts to toggle between (waybar), didn’t realize I could just rotate in a completely new TLP config file (derp).
There isn’t, it was just recommended to use PPD over TLP for the 7040U frameworks (and they are conflicting packages in arch).
I went through the suggested tunings in powertop, and found the runtime PMs made the most difference (PPD doesn’t set those, TLP did but we are told we shouldn’t use it now).
This just seemed like a lighter-weight alternative if (for me) it gets me 90% of the way there.
Playback of the bunny video mentioned above is 7.5 to 8W using software- and 6 to 6.5W using hardware decoding. Intel i5 1240p, ~25% brightness, fedora 37, mpv.
I think this is the right topic, but it appears that the AMD wifi card doesn’t work with suspend-then-hibernate (how are so few people using this functionality???):
At least mention the fact that you wrote the patch, it has not been widely tested or dissemintated, and that you will now be running a tainted kernel.
Not sure myself if this is the right topic, but hey it ain’t completely wrong. As to why so few people use suspend or suspend-then-hibernate well I know for my part I would prefer to shut down in those instances for what are ultimately security reasons. A variety of attacks rely on the device already being powered on and in some form of operation, and yes I do have to concern myself with this to a degree so it is a reasonable precaution. Others likely don’t have these concerns and for them I can only speculate that it is the second reason I never use suspend or hibernate. I have been using linux exclusively for 14 years now, and at no time I remember has either operation worked flawlessly, or without a bunch of manual intervention. Even after it was working it woould break every couple of updates or everytime new processors got added to the kernel. It has to be one the most common “regressions” there is, and the fact that intel and amd both mess with sleep states on a regular basis does not help a bit. So it comes down to knowing what works most reliably for the least amount of effort i.e. this is a fiddly bit that has little intrinsic value outside of a perceived convenience. Back in the day when it took more than 10 seconds to boot I get it, but now the juice is just not worth the squeeze.
Same haha, though it is for Linux and can save battery life. My 2c: suspend-then-hibernate was quite involved with zero knowledge. It can be lot of work (1, 2, 3), and even after that, testing dependability and troubleshooting resumption issues were a pain. That’s with me being a bit lax-security wise (because I understand the implications).
However, since then, it’s been running flawlessly on 11th gen Intel for over a year (through multiple Fedora version upgrades) and (“miraculously”) still works on AMD. It’s been invaluable to me for saving battery as I have my system set to 1. automatically hibernate after suspending for 2 hours and also 2. hibernate at 7%. Therefore, I won’t lose more than 2 hours of battery life %tage on suspend, and shouldn’t ever lose the state I was working on. It also skirts the issue many people had with losing too much battery life overnight during sleep. Sidenote for just hibernation: it has proven immensely useful when I need to boot into another distro to use/test something but don’t want to lose my state, e.g. the rare Windows app. Or even just changing BIOS settings.
It seems there’s been a bump in demand for good UX here since it’s the year of desktop Linux (¿). I’m hoping the Fedora team can figure out how to in Workstation (or whatever distro) so that it can propagate throughout the ecosystem. It does require enough users to provide feedback and testing, so this is also my recommendation to the community try it out (with precaution)! Before, varying hardware configurations made it hard to have a troubleshooting critical mass, but it’s easier here since we run the same or similar hardware.
Maybe we should have a thread dedicated to hibernate/suspend-then-hibernate?
I. Trying to copy @Mistral24’s testing methodology.
My test setting was always:
1.) idle (20% Backlight; no running apps (except Konsole with powertop open); after 2 mins);
2.) light browsing (Firefox with 5 tabs of google searches open);
3.) writing a text in Libreoffice;
4.) watching Youtube Video (1080p; av1, speakers at 25%).
Wi-fi is on, Bluetooth is off.
AMD Ryzen 5 7640U.
I’m using Fedora 39 Beta & KDE Plasma with Kernel 6.5.8
There is a very big difference in switching to TLP, and I haven’t even fully optimized it. The difference for me is especially noticeable in my actual day to day usage, which is more like a couple dozen tabs in Edge. I’ve slashed my power consumption by about 30-40%.
Thank you very much @Michael_Wu for the in-depth documentation (I might have stolen your TLP config )! I’m still having fairly high power consumption on Youtube, which is probably because of the freeworld drivers.
set on FC39 kernel ; I would advise that a disclaimer is added to the top post as this appears to be a dangerous combination with recent kernels and the AMD7040
I tried using power-profiles-daemon on a 7840u, but for some reason it seemed to limit igpu performance even on the performance mode. The igpu would not boost above 800 Mhz. Has anyone experienced this? I am running arch on the 6.6 kernel and 3.03 BIOS.
I have since switched to TLP and it the igpu boost behaves as expected with much better performance. I also think I am getting better battery performance with TLP, although I have not thoroughly tested.
Sure thing! That’s why I posted it and so that it can be used as a starting base for further discussion I’ve been using my AMD laptop off and on (but not much heavy use) the last week while traveling and battery life has been much better than my previous 11th gen mainboard (didn’t measure hard numbers though).
I’ve had great success TLP + Ubuntu (Wayland/Gnome) on my Intel 13th gen framework, but one thing I’ve noticed is that when on battery, gestures with the touchpad to change workspaces are terribly slow. If I switch TLP off or switch to AC, they become smooth again. I’ve played around with the TLP config a bit and none of my modifications seem to address this particular issue; I assumed it would be graphics related, but perhaps not?
Note: when I switch workspaces using the arrow keys it is quite smooth! Also, when I switch off the PCIe Runtime PM on BAT it gets a teeny bit smoother. But not enough.
Likely a Gnome issue, most likely, the animation is just too CPU intensive on a single thread (which TLP heavily affects).
I used to have this issue on Gnome, but haven’t experienced any lag on Hyprland.
Looking towards the future:
I think we/framework should make a more dummy proof solution here.
Can we maybe brainstorm a bit?
For example; would it be possible to create a TLP configuration file and share that via an official “guide”?
At the moment, and in the near future, it will be very difficult for the medium-tech-savvy people to optimize their new laptop in linux.
AMD is a new platform; I expect (configuration) improvements to happen from time to
time.
And every bios release, people will find configuration improvements for battery optimization.
For all distro’s, every framework user probably benefits from the same configuration.
But not all of us have the time, or the hobby, to follow all the posts to stay up to date all the time.
What would be a good way to enable the whole community to stay as energy-efficient with their framework laptop as possible?
I attempted creating a custom Fedora image with the power saving techniques applied by default, you can see my original post linked below.
Totally agree with you though. Fundamentally for new users I think there needs to be a better out of box experience. System76, Slimbook, Tuxedo, and others have their own power management packages. I think it would be nice to have an official guide vs us cobbling things together after hours and hours of research that 90% of people would never do.
You really need a custom kernel with your Ublue images I think to make this really worthwhile
There are several patches which apply to the amd framework that are worthwhile.
Namely:
amd-pstate epp prefered cores
rtc-cmos fixup
cros_ec
PPD epp preference switching support
systemd tuning for auto power save for framework modules
packaging for ectool to support the EC querying
6.7-rc2 doesn’t include any of the above but DOES include power-supply fixups and amdgpu patches ; and is likely a good target to apply the above patches too (i’m using the fedora rawhide os-build as a starting point ; and have the above patches applied to my install).
Fedora kernel policy is NOT to include patches that have not already been accepted into the mainline kernel, and IMNSHO if you are going through the trouble of building an ostree image - shipping a custom kernel is a trifle to include.
OOTB apart from the PPD patch the userspace in FC39 is pretty spot on and there are not that many tweaks without the above out of distro/tree patches worth the effort of maintaining a specialized image for the fwamd specifically - sans kernel.
The two bits of hardware I am struggling with to find a working patchset are:
the USB-PD usci errors and ack bugs - this is still an issue and I’ve had instability with state changes around plug/unplug events leading to quite disturbing behavioiur with i.e upower reporting AC is present when it’s not and/or not triggering dbus on unplug to signal to PPD. This is AFAIC a kernel level/firmware bug with the PD controller interaction and should probably get a bit more attention from framework.
amdgpu issues with Memory management are still present for the phoenix platform, although potentially this might be fixable with a newer Framework BIOS patch for the AGPU.
And the last one is the Ambient light sensor - Can someone please let me know what model is in the amd framework? I’ve tried a number of out of tree patches for various ALS chips but I still can’t get the kernel to instantiate it correctly.
)! I’m still having fairly high power consumption on Youtube, which is probably because of the freeworld drivers.