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.
Custom kernels by their nature automatically exclude people who don’t want them. I know I will automatically write off an image with a custom kernel for a number of reasons, and i am very likely not the only person. Custom kernels are quite literally an individual preference, So if they feel like adding one in addition to a base image great, but as the default I would have to say no.
Well the reality is right now; there is no other viable option than out of tree patches .
IME running older kernels with out of tree patches is worse than running the current vanilla head with patches. But you are right this is a personal preference. I guess I just look at the huge ammount of resources required to build-pipeline a whole ostree image when all that really is needed is a simple ansible playbook to be run against a base install which is all that that is really needed for FC39.
packaging of ectool probably should go to fedora packaging for inclusion ; and the systemd device ID’s should hopefully make there way into updates in the normal packages given I think @linuxlion submitted them upstream.
Everything else current is dependent on out of tree or non-existent bits or in PPD’s case a non-accepted patchset.
I wouldn’t assume that everyone here knows how to do what you are referring to. I have never built my own kernel, and I would assume the vast majority here haven’t either, nor would they know how to install a patched PPD.
I was trying to look into setting up COPR repos, but have zero experience with that as well. It sounds like you may have the know how / experience. Would you want to create a COPR for the PPD / Kernel with relevant fixes applied?
A copr is a relatively good proposition. However a ublue ostree image is probably an easier way to distribute this and won’t require setting up i.e kernel signing keys/spec files etc; and whoever maintains the ostree image with custom kernel bits etc can do so much more easily.
Ideally the bits t hat can goes into upstream rawhide, and kernel bits will filter through eventually. But for today - given the OP has already started down an ostree style path - simply building on that is much simplier as it’s a matter of adding a tag to their existing image and pushing a whole delta of the osimage with the custom kernel/packages etc included.
There is already a framework ublue image (but currently for the intel only). And it would be simple to have a framework-amd13 split out with and without out of tree bits.
This would effectively be similar to other ublue images which include a heap of changes to base kernel/modules userspaces OOTB
For reference I get nothing - I had hoped this might have been some sort of magic init string I was missing but no.
** (iio-sensor-proxy:13116): DEBUG: 07:57:54.043: Starting iio-sensor-proxy version 3.5
(iio-sensor-proxy:13116): GLib-GIO-DEBUG: 07:57:54.045: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)
** (iio-sensor-proxy:13116): DEBUG: 07:57:54.085: No sensors or missing kernel drivers for the sensors
root@emiemi:/var/lib/power-profiles-daemon# sudo iio_generic_buffer -A -N 0
iio device number being used is 0
Failed to read name of device 0
I did some power testing and have to say am a little bit disappointed when comparing it to my beat up t480s. Sure it performs a hell of a lot better and the bigger battery also makes up for some of it but it is kind of frustrating seeing something much newer struggling to even match the low load efficiency of the old one.
Test setup is the AMD 13, 7840U, 2x32GB Kingston 5600cl40, 2Tb 980 pro and an ax210 (3usb-c and one usb-a in the front left slot for expansion cards, removing the a made no visible difference). My previous I am comparing it to is a T480s, i5 8250u, 36GB(4+32), 256GB 970 evo, ax210, LTE modem, built in unifying receiver (that draws about 0.1-0.2W all the time) and a modded in 1440p panel. Both run a relatively light arch+sway install with tlp and the thinkpad is undervolted.
Tests are run with wifi connected (about 2m from the access point), bluetooth on but not connected, display at 20%, keyboard backlight off, webcam off(physical switch or complete delete), microphone off on the framework. All measurements are taken with powerstat after they settled for a bit.
I am using the format [TEST] [FW 13 value]/[T480s value]
Idle (just sitting with 2 terminals open) 3.5W/3.4W
Idle with firefox open (a videos page on youtube) 3.8W/3.5W
Iperf3 (continuous runm wifi6 80mhz) 8.6W/6.3 (performance was roughly equal)
firefox hardware accelerated 720p 30hz (vp9 for the fw, h265 for the thinkpad) 8.5W/6.9W
Idle looks at least not worse but I think something with the hardware acceleration isn’t fully baked jet or something I can’t believe that a h264 decoder on a much newer node somehow actually needs more power than the old one, I hope this is fixable in software at some point.
One thing to remember is that you really need to compare total consumed power over time for a job run; especially when paired with the epp prefered cores patches (basically ‘good cores’ on zen dies are ones that can boost higher for lower power input) means you have cores boosting high and finishing jobs quickly and drawing less power.
3-4W idle seems pretty good considering that’s as low (or lower) than a recent ARM SBC like an rk3588 - which can’t get anywhere near the same performance states as the zen4.
Doing a timed kernel compile test run and watching power use and time for it is going to provide a better reference point than monitoring idle ‘hypermile’ use.
My main usecase for battery is ‘can I get through several site vists in 2hr blocks without needing to reach for a Power Plug’ which I think this configuration manages pretty well.
Would I like a couple more hours runtime, yes. But Hopefully at some point battery Cell replacement with a higher ah rating might become an option.
