Might be the abm, I think they made that enabled by default lately. In my testing on the 13 the higher abm levels made the colors look a bit washed out at lower brigthness levels.
I had a similar thought but I run near minimum brightness. I just saw a post on Mastadon from KDE sharing that themes can execute arbitrary code and one in particular was found to be running rm -rf on user data directories. I did just try a couple themes shortly before noticing this issue, so I’m gonna see if any of them executed something.
Well that’s lovely.
Could just try turning off abm and see if that helps though, pretty easy to eliminate just a kernel parameter.
Fair, it’s easy enough to test.
Yes; ABM can have this effect, this is why it’s dynamic and not turned on very aggressively by PPD unless you’re in power saver.
1 Like
Well, I booted up without my forced abm. While I can’t quantitatively say if the screen actually looks different, the screen does feel different.
In fear that I was making it up and gaslighting myself, I asked my gf to help with some A/B tests. During boot, she randomly selected a kernel config, and based on the display I was able to correctly guess which config she selected 6 out of 7 times, being wrong on the first try.
I guess I’ll just be not messing with that parameter for the moment and wait for 6.9 to come around.
# LED Matrix, ModemManager should ignore
SUBSYSTEMS=="usb", ATTRS{idVendor}=="32ac", ATTRS{idProduct}=="0020", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
CC @DRACONIUM
1 Like
Another reason we need an AUR packages for Framework-(13/16)-(intel/amd) udev rules, audio tweaks, and dependencies.
That’s just one of the several things mentioned.
Finally figured it out. The confusing part was that you can’t just ignore all the things from sensors output, as they are “subfeatures” and lm-sensors only supports ignoring “features”.
This /etc/sensors.d/dGPU.conf did the trick:
chip "amdgpu-pci-0300"
ignore in0
ignore temp1
ignore temp2
ignore temp3
ignore power1
ignore fan1
This will ignore all the sensor features of the dGPU and thus lm-sensors will no longer wake it up.
Next step is to make it dynamic on dGPUs suspend state.
Note: My dGPU is at PCI address 03:00.0 . You may have to check your address with lspci | grep 7700
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 33 [Radeon RX 7700S/7600/7600S/7600M XT/PRO W7600] (rev c1)
1 Like
Hey all, So I am new to running linux outside wsl, and decided to torture myself by using arch as my first install. I followed the installation instructions, I have KDE-desktop as I didnt want their browser and email client etc, that comes with normal, as well as hyprland, switching between both to see what I prefer long term. My biggest fear is that I am missing something I should have to have full utility. So if anyone wants to dm me with any resources to check out or guidance on stuff I should make sure to install, please let do.
I also was hoping to undervolt, I got the 7940, and was just wondering if anyone has tried undervolting in arch, or another distro, and if so, what tool did you use so I know what to look into for my potential attempts.
Thanks in advance for anyone that decides to help me out here or that has any info for me.
Hm, I need to figure out why my idle power consumption is so high (15-25W). Most likely it’s because of the dGPU, but I haven’t had a laptop with a dGPU before and need to read into how to check up on it properly. Otherwise I ran powertop and enabled everything but things like keyboard idle (that is atrocious, I hope no one uses that). Are there tricks I could apply to lower my power consumption? Currently I’m not hitting more than 3-4 hours on battery, which is obviously not what this laptop should be able to.
Install PPD 0.21, just released today.
Also check if your dGPU is awake. Any sensor reading software can keep it awake.
3 Likes
To check the power state of the dGPU, you can either use framework’s python script for Fedora here or simply
cat /sys/class/drm/card1/device/power/runtime_status
it should show suspended if not in use. If it says active instead despite nothing obvious is using it, it may be due to lm-sensors querying it in the background or even periodically through some sensor widget. On mine, it was gnome-shell-extension-sensors / gnome-shell-extension-freon and I was able to ignore the dGPU in lm-sensors, see Arch Linux on the Framework Laptop 16 - #91 by motzky80 above.
Hype!
Hm, it says active but I’m not sure what triggers it. I killed most stuff (even XWayland) and am running on Hyprland. There’s likely something I’m missing.
I tried looking for tools that tell me which process might be keeping my dGPU powered on, but didn’t find any. There’s nvidia-smi which seems to do that for nvidia gpus, but I didn’t find a useful flag to use with rocm-smi which would reveal that information.
Is there any way to find out what’s keeping my dGPU from idling properly?
Ninja-edit:
Just thought to try KDE Plasma and sure enough, the card idles properly over there.
Hmm. Guess this is on Hyprland, I’ll try downgrading it and see if it was a regression or something I need to configure. I did try configuring it according to the wiki, but that site has changed now and advises to do nothing if you want the default to be the iGPU (which should be used automatically).
You can also use watch -n 1 cat /sys/class/drm/card1/device/power/runtime_status to monitor the status of the dGPU in (near) real time.
Yeah true. Like I said in my ninja edit, dGPU idle works fine in Plasma (Wayland). Just need to figure out why it doesn’t in Hyprland.
1 Like
Hm, I added the env var for Hyprland to use the iGPU according to their wiki, but the dGPU still isn’t sleeping in Hyprland.