Recently switched from opensuse tumbleweed to NixOS, really enjoying it, but I am now having issues with suspend and niri, more specifically after suspend niri is completely frozen, apart from the frame occasionally updating maybe once a minute. It can be fixed by dropping into a TTY session and restarting niri (systemctl --user restart niri.service), this is not ideal however as all the open applications are lost.
This is a list of everything I tried so far (nothing worked)
Switching to nouveau
Trying different modes on nvidia driver (Offload mode, sync mode, etc)
Switching to latest kernel (which was version 7.0)
Switching to niri unstable and stable channel
I tried with kde an suspend still worked fine there, so it really seems to be a niri issue, not anything with the nvidia driver or kernel.
hardware.graphics.enable = true;
# GPU driver stuff (not sure if amdgpu is needed for integrated graphics?)
services.xserver.videoDrivers = [ "amdgpu" "nvidia" ];
hardware.nvidia = {
open = true;
# TODO: prime (dual gpu) setup?
prime = {
nvidiaBusId = "PCI:1@0:0:0";
amdgpuBusId = "PCI:5@0:0:0"; # If you have an AMD iGPU
offload.enable = true;
# sync.enable = true;
};
};
programs.niri = {
enable = true;
package = pkgs-unstable.niri;
};
In the logs there seems to be some permission denied error, after waking from suspend
mei 16 09:01:21 nixos-laptop niri[1923]: 2026-05-16T07:01:21.222927Z WARN niri::backend::tty: error queueing frame: The underlying drm surface encountered an error: DRM access error: Page flip commit failed on device `Some("/dev/dri/card1")` (Permission denied (os error 13))
mei 16 09:01:21 nixos-laptop niri[1923]: 2026-05-16T07:01:21.225125Z WARN niri::backend::tty: error queueing frame: The underlying drm surface encountered an error: DRM access error: Page flip commit failed on device `Some("/dev/dri/card2")` (Permission denied (os error 13))
I don’t think this is an issue with upstream, because niri suspend worked fine while I was using opensuse.
Any help would be greatly appreciated
PC specs and info:
OS: NixOS 25.11 (Xantusia) x86_64
Host: 82EY (IdeaPad Gaming 3 15ARH05)
Kernel: Linux 6.12.90
Display (PLE2483H): 1920x1080 in 24", 60 Hz [External]
Display (CMN15E7): 1920x1080 in 15", 60 Hz [Built-in]
WM: niri (Wayland)
CPU: AMD Ryzen 7 4800H (16) @ 2.90 GHz
GPU 1: NVIDIA GeForce GTX 1650 Ti Mobile [Discrete]
GPU 2: AMD Radeon Vega Series / Radeon Vega Mobile Series [Integrated]
The kernel will load that driver automatically if needed, unless you turn that off via sysctl. So it shouldn’t be necessary. At worst it affects module load order, but that shouldn’t matter much.
services.xserver.videoDrivers is otherwise only used to check if it includes nvidia.
All those options only set X11 config. “Prime” is an X11-only feature. Wayland compositors handle multi-gpu setups natively.
Wlroots-based compositors use this env var to choose the primary GPU, or whichever handed off rendering from BIOS, which is firmware-dependent (and may have a BIOS toggle).
You can try using the hardware.nvidia.powermanagement.enable setting; without it the nvidia driver’s suspend feature is disabled, so you’re likely not storing all GPU memory. I know, this should be set by default, the NixOS nvidia module makes very little sense.
If that doesn’t work, there’s not much else to debug here, this is either an nvidia driver or upstream bug. You’ll have to talk to the niri folks (who may not be able to or want to help) or nvidia (who are too busy buying governments to care).
Edit:
… wait, that’s a 1650Ti, is that even still supported by modern nvidia drivers? What does nvidia-smi tell you?
The 1650ti is a Turing chip, so it should still be supported. Including by nvidia-open I believe.
Why isn’t that power management setting default? Also, last time I tried the fine grained power management option, I got eval errors stating I needed to set the prime GPU IDs. I’m using wayland so I never bothered with those IDs.
I don’t know. Ask upstream. Maybe to make the module just work™ on old cards that aren’t supported by the current driver anyway and therefore won’t? I suspect nobody cares too much, the module needs a rework and consistent vision, trying to interpret it doesn’t really help.
Ah, that sucks. Last time I looked closely at it you could still flip the option on without those. Unfortunately its default setting will forcibly turn off finegrained powermanagement, even though modern nvidia GPUs are set to enable it by default.
So now you probably need to set those pci settings even though they are completely unused. Plus you don’t get to rely on the GPU defining whether it supports this or not. Whatever, the X11 config is pointlessly generated anyway, what’s a few dozen extra bytes
That said, I’m talking about the powermanagement.enable option, which has nothing to do with the finegrained option, besides sharing a name - I suspect they ended up under the same top-level option by accident rather than on purpose. They are under completely different headings in the nvidia docs and do different things (one saves graphics memory on suspend, the other turns off the GPU if it isn’t being used).
I don’t know why the options don’t just say so. Did I mention that the NixOS nvidia module is a mess?
Setting hardware.nvidia.powermanagement.enable = true fixed it! Thanks a lot. Had no idea prime was x11, good to now as I am currently not using x11 at all. My user was already added to the video group, so that wasn’t the issue.