Can you please post a video of what you mean? I don’t expect that behavior at all.
If it’s a USB mouse it sounds like it’s configured for autosuspend and you should turn that off. This isn’t caused by PPD, maybe some other policy you did turned it on.
If it’s the touchpad or both can you please try to turn off PSR using the amdgpu debug parameter?
Of course I don’t mind, thank you so much for doing this (was just about to do it but saw it in AUR 
)!
Cheers, it’s working great.
Nevermind, upon some further testing I realized that even without your PPD patch, my touchpad is behaving erratically. I guess that some update in libinput or the kernel borked something for me.
Cool, yet another problem 
It seems like 6.6.7 broke something for me.
I have gone back to UMA auto in the BIOS, removed the PPD patch, but nothing worked until I reverted to a snapshot from a few days ago, which runs 6.6.6 (I thank Tumbleweed’s snapshots OOTB every day!).
Not the topic of this conversation anyway…if I feel brave enough I may give the patch another try, but right now I’m just too happy to have my system back as it should, that I’d rather keep things as they are for a bit 
Gaming was terrible too, with constant lag and audio freezing. Dunno WTF happened but I guess I’ll stay on this kernel for a while.
Same values here, also on Arch + KDE (did not check the monitor off state), without any ill side-effects so far, thanks @efindus for the package!
After @Mario_Limonciello’s post about abmlevel, I included that in my testing with the following settings & results:
Seeking the holy grail, enabling powertop --auto-tune made little to no difference as:
Based on this latest and past testing detailed here, I’ve posted a power management guide.
Happy 2024!
Woof! I knew it took awhile but have always just kept working normally while powertop is taking measurements.
I’m also trying to figure out the best way to measure power usage here, and am I correct in saying that are only two sources (not counting things like an external power meter of course):
the battery charge level at (which of course only works when you’re not charging it:
/sys/class/power_supply/BAT1/charge_now
and the rapl interface at (it has the name package):
/sys/class/powercap/intel-rapl/intel-rapl:0/energy_uj
What does this second one actually measure? The entire APU’s energy usage? Or just the CPU part (somehow)?
Comparing the two values on my framework using this script (there’s some rounding errors due to the per-second polling):
I get about a 5W difference or so between the two values (e.g. rapl shows ~2W draw, battery shows it’s draining about 6.9W, this is at 6% brightness)
There’s also a second rapl device, intel-rapl:0:0 that has the name core, but that only reports really tiny amounts (in the 0.1w range)
Thank you for the support to our distro @efindus !
I also comment directly in the AUR package page because I had an error when I try to install it. Here the details:
Hunk #1 FAILED at 263.
Hunk #2 succeeded at 809 with fuzz 1 (offset 181 lines).
Hunk #3 succeeded at 854 with fuzz 1 (offset 173 lines).
Hunk #4 succeeded at 906 with fuzz 2 (offset 170 lines).
Hunk #5 succeeded at 946 with fuzz 1 (offset 169 lines).
Hunk #6 succeeded at 975 (offset 169 lines).
1 out of 6 hunks FAILED -- saving rejects to file tests/integration-test.py.rej
==> ERRORE: Si è verificato un errore in prepare().
L'operazione sta per essere interrotta...
-> errore durante la creazione: power-profiles-daemon-patched-amd-git-exit status 4
-> Installazione dei seguenti pacchetti non riuscita. È richiesto l'intervento manuale:
power-profiles-daemon-patched-amd-git - exit status 4
My system:
Host: Laptop 13 (AMD Ryzen 7040Series) A7
Kernel: 6.6.9-arch1-1
DE: Plasma 5.27.10
Any ideas? Thanks in advance.
Just delete the part patching the integration tests from the patch. You won’t need them when using the patch and they all conflict.
Confirmed, as this is what I did.
Don’t use an AUR helper, you’ll see which hunk failed. and remove the code from the patch files, 128/129
The problem is the code review was pedantic about changing whitespace when the existing code has problems and is consistent. So now there is a conflict depending on the way that they merge.
Yeah, it can be a bit frustrating at times, but in this case for applying the patch locally, it works well enough to just delete that part of the diff. Looking very much forward to this being in an official release though, thanks a lot!
I’ve tried to resolve the conflict. I split off the common change to 130. So if you merge 130, 127, 128, then 129 I think it will work.
thanks for your work on this. My power draw is significantly better. I can watch youtube and temps are normal now
Tried to merge in this order with NixOS but still facing rejected hunks
Already tried it. The patches have changed since and now have conflicts.
The commit in 130 is also in 127/128/129. So you need to use merge not cherry pick. By using merge git figures it out and doesn’t apply the identical sha1 twice.
It’s been approved! Hopefully will get PPD v0.14 very soon with all these MRs included and now the new baseline for PPD.
Great job Mario!