I accidentally edited my previous post instead of posting a new reply. Oops!
My config as linked previously: nix/default.nix at main - nix - git.lyte.dev
The Arch Linux wiki entry for Framework 13: Framework Laptop 13 - ArchWiki
In case anybody else is interested in this. here is my attempt to bring @Mario_Limonciello’s PPD patches to NixOS: [TRACKING] PPD v TLP for AMD Ryzen 7040 - #137 by Wrybill_Plover
2 Likes
Does anyone else have WiFi hand off issues? My Framework will hang on to an AP that has so little signal I can’t even send/receive pings rather than switch to the one next to it as I move around my work. I have to toggle airplane mode or click the WiFI name in the drop down for it to switch (I’ve tried letting it wait over 5 minutes).
AMD 7840 with the RZ616 wifi card would switching to the ax210 card fix the issue?
Yes! I was thinking just earlier today that I should post somewhere on the forum. (Although it is offtopic specifically here, as this has nothing to do with NixOS.)
I have two APs with 802.11k and 802.11v configured, and roaming works flawlessly with all other devices (phones, macbooks, my other Dell laptop), but the AMD framework stubbornly stays connected to the AP with an absolutely unusable signal level when I am already right next to the better AP (while other devices roam mid-way).
Only reason I posted here was because I’m running NixOS and didn’t have a problem with my previous laptop (Arch) but it does have a different WiFi card. Searching for WiFi hand off issue usually just pulls random issue that aren’t related.
Hmm maybe I should post in the Nix forums and hope an expert there can tell me something I should add to my config.
Another AMD fix: installing a beta VCN firmware blob to address VAAPI VP9 decoding glitches (see Active upstream AMDGPU issues affecting Ryzen 7840U (iGPU 780M) - #8 by paulos):
# beta firmware blob to fix VAAPi VP9 decoding glitches
# (see https://gitlab.freedesktop.org/mesa/mesa/-/issues/8044#note_2195102 and
# https://community.frame.work/t/active-upstream-amdgpu-issues-affecting-ryzen-7840u-igpu-780m/41053/8)
hardware.firmware = [
(
let
betaVCNblob = builtins.fetchurl {
url = "https://gitlab.freedesktop.org/mesa/mesa/uploads/f51d221a24d4ac354e2d1d901613b594/vcn_4_0_2.bin";
sha256 = "sha256:0rg4sm6sivn6s356cnxgfqq5d7gg2f3ghwi3psc0w6i7pks3i3z8";
};
in
pkgs.runCommandNoCC "betaVCNblob" { } ''
mkdir -p $out/lib/firmware/amdgpu
cp ${betaVCNblob} $out/lib/firmware/amdgpu/vcn_4_0_2.bin
''
)
];
Turned out to be easier than I expected: the copied file automatically replaces the one provided by the linux-firmware package.
The sha256 value of the blob is notable 
4 Likes
Hi all,
Random question has anyone had any luck getting an eGPU working with all-ways-egpu on NixOS?
I was wondering if we needed to do any extra to make it work with NixOS!
Thanks!
I believe one person got it to work by using the latest kernel.
Hello,
I am experiencing some glitches on latest kernel with Plasma/KDE: this only appears on 6.7. Anyone has seen something similar, not sure where to check for a bug report/issue
What are “some glitches”?
sorry, I mean graphical glitches, the screen becomes segmented into pixelized blocks, like a chess mat, very distorted view. it happened at least 3 times, but it seems I am now unable to reproduce 
EDIT: I was able to reproduce, and as I remembered, nothing show on the journal/system logs
here is a picture
I’m having a similar problem with gnome but white screen or hyper flashing on the newest kernel I just removed that line and went back to the stable kernel.
amdgpu.sg_display=0 didn’t help me but some people report that it fixes the issue.
For those who don’t want to wait until next PPD release (with fixed AMD stuff), I want to share the code to compile git version. Provided that you use flakes:
*config.nix*
nixpkgs.overlays = [
(_final: prev: {
power-profiles-daemon = prev.power-profiles-daemon.overrideAttrs {
src = inputs.ppd-src;
};
})
];
*flake.nix*
inputs = {
ppd-src = {
url = "gitlab:upower/power-profiles-daemon?host=gitlab.freedesktop.org";
flake = false;
};
};
Another method is to use the services.power-profiles-daemon.package option with the overridden package version. An advantage of this approach is it won’t trigger rebuilds of dependencies.
services.power-profiles-daemon.package = pkgs.power-profiles-daemon.overrideAttrs {
src = inputs.ppd-src;
version = inputs.ppd-src.rev;
};
Example configuration.nix changes.
4 Likes
I’m thinking of rolling a systemd module for keylightd. Did anyone do this already? don’t want to duplicate work.
3 Likes
Note however that this option is very recent and only exists in unstable at the moment.
I’m not sure this config actually does anything… your extra firmware package provides a file with the same name as the one in linux-firmware, so it will be a collision and, when building the firmware directory, collisions are resolved in favour of linux-firmware (because it has meta.priority = 6, while the default is 5). So you need to either bump the priority of your package or, what I would argue is a cleaner solution, tweak the actual linux-firmware package (kind of as if you were applying a patch) e.g. by overriding its postInstall.
I think, this is what actually is happening here, due to the entire expression being evaluated as a part of hardware.firmware.
You can confirm that it works by checking what version of VCN has been loaded, e.g., by sudo dmesg | grep "Found VCN". Without the override, I am currently getting version 1.10:
[ 1.902575] [drm] Found VCN firmware Version ENC: 1.10 DEC: 5 VEP: 0 Revision: 0
with, I get version 1.17, Rev. 10, as expected:
[ 1.896711] [drm] Found VCN firmware Version ENC: 1.17 DEC: 6 VEP: 0 Revision: 10
Like I mentioned, this turned out to be easier to implement on NixOS than I expected… But, if it doesn’t work for you, please let me know.
I’d love a submission to I have the same screen flashing issue. What version of the kernel are you using?