Hi,
I just installed NixOS on my big PC and I am facing issues with Nvidia graphics card (RTX 4070) and sway.
The screen is flickering A LOT, it is almost unusable…
I saw a lot of posts about this subject from about a year ago, is there any changes to the issue with recent driver versions ? I saw that explicit sync was now supported on latests open source drivers. I tried stable and beta with no more luck.
Anyone having success with this ? Switching to another window manager is not an option, I don’t want to loose weeks changing all my hosts to something else…
That’s the default. Please stop feeding the cargo cult.
Yep, it is, and has resolved most of the issues on wayland. Your compositor must also support it, though.
This merged for sway and wlroots at this point, and NixOS 25.05 now has a sway version that does this correctly afaict. It’s working on my 4060 anyway. NixOS 24.11 is stuck with an old wlroots that does not.
Can you tell us the versions of the nvidia driver (nvidia-smi) and sway (sway --version) you are running?
Share your config while you’re at it, you can break the driver config pretty easily.
Thank’s for the help !
I will give you the nvidia driver and sway version this afternoon when back from work.
My config is quite messy, but here is what I think is the relevant part. It’s flake managed and I’m under nixpkgs unstable for now:
{ config, lib, pkgs, ... }:
{
imports = [
./hardware-configuration.nix
../common
../common-sway
];
# Bootloader.
boot.loader.systemd-boot.enable = true;
boot.loader.efi.canTouchEfiVariables = true;
# boot.loader.efi.efiSysMountPoint = "/boot/efi"; # Disabled, no idea why it is there. Re-Enable if errors with systemd or bootloader
# Nvidia
# Enable OpenGL
hardware.graphics = {
enable = true;
};
# Load nvidia driver for Xorg and Wayland
services.xserver.videoDrivers = ["nvidia"];
hardware.nvidia = {
# Modesetting is required.
modesetting.enable = true;
# Nvidia power management. Experimental, and can cause sleep/suspend to fail.
# Enable this if you have graphical corruption issues or application crashes after waking
# up from sleep. This fixes it by saving the entire VRAM memory to /tmp/ instead
# of just the bare essentials.
powerManagement.enable = false;
# Fine-grained power management. Turns off GPU when not in use.
# Experimental and only works on modern Nvidia GPUs (Turing or newer).
powerManagement.finegrained = false;
# Use the NVidia open source kernel module (not to be confused with the
# independent third-party "nouveau" open source driver).
# Support is limited to the Turing and later architectures. Full list of
# supported GPUs is at:
# https://github.com/NVIDIA/open-gpu-kernel-modules#compatible-gpus
# Only available from driver 515.43.04+
open = true;
# Enable the Nvidia settings menu,
# accessible via `nvidia-settings`.
nvidiaSettings = true;
# Optionally, you may need to select the appropriate driver version for your specific GPU.
package = config.boot.kernelPackages.nvidiaPackages.beta;
};
networking.hostName = "jm445-pc"; # Define your hostname.
programs.nm-applet.enable = true;
# Firewall
networking.firewall = {
enable = true;
allowPing = true;
};
users.users.jm445.extraGroups = [ "docker" "wheel" "networkmanager" ];
# Greeter Specific config
environment.etc."greetd/hostSpecificConfig".source = ./greetconfig;
}
These are all defaults, you should delete all of it
The beta and stable drivers are currently equal, since NVIDIA just released a stable driver. You could pin a specific driver version if you wanted to, but honestly just keeping that on stable is best.
Other than nits though, looks fine.
Would be helpful to see your flake inputs, too. VRR can sometimes cause issues, so try turning it off; it’s one of the sway output settings.
Yep, looks like it’s all correctly set up then. I don’t see anything from the flake that would imply it is not either (though there are more nits I could throw your way).
I’d check monitor settings, make sure to try and get things working on 1920x1080@60Hz before trying VRR or anything else crazy, if that doesn’t work check with X11 to see if the flickering is present there.
If not, you’ll have to go to the nvidia forums, if it is present, sounds like faulty hardware.
Is there a software option to disable VRR ? I disabled FreeSync on my monitor with no more luck and can’t find any related option in nixos documentations.
Also is there a quick and dirty way of trying with X11 without having to design a fresh new setup with another window manager ?
I just noticed something that could say this is not fully a driver related issue: Screen flickering only happens on some apps only: the apps using electron like Discord, Spotify or google chrome. No flickering on sways “desktop”, neither in alacritty, nor in Steam. That’s strange because I already had electron issues with wayland a long time ago and thought I had fixed the issue. I can’t remember how I did that fix but I will investigate my config to see if there is traces of that
Hmm, those would likely all be using xwayland. Do you see the same behavior in firefox? I just recently ditched my last Xwayland application, so there nay be bugs I’m unaware of I guess.
The sway from nixpkgs-wayland is built directly from the upstream main branches, which depending on how releases ended up slicing into 25.05 may have some important patches the version in 25.05 is missing.
No issues with firefox.
Is the sway from nixpkgs-wayland newer than the one on unstable branch ?
And should I use it as an overlay or just set program.sway.package ?
Yes, and importantly, so is the wlroots it is compiled against.
The latter is my preference, in practice it does not matter that much.
The difference is that using an overlay replaces all versions of the overlayed packages in the pkgs variable your nixpkgs config uses, recursively (so also in the dependencies of other packages). Setting the package option only replaces the binary that’s actually running.
So overlays are more expensive to evaluate, and cause mass rebuilds, but useful and important if e.g. you want to get rid of an old version of openssl, or replace a commonly used library with a fork or something. OTOH, if it’s just a “leaf” package whose binary you execute and that nothing else really links against, setting the package option burns a bit fewer watts on your electricity bill and is less likely to leave you with surprises.
In this case, other things may link against wlroots, but probably don’t and even if they do they’re unlikely to be incompatible with the running sway. Sway in turn interacts with your applications primarily through its IPC socket and the wayland protocol, so it should be agnostic to build-time differences.
Actually, I can’t find a way to use their sway in program.sway.package. There is no sway package inside nixpkgs-wayland, and the “sway-unwrapped” package gives me an error at rebuild:
error: Package, 'sway-unwrapped-+6816b51', did not specify any session names, as strings, in
'passthru.providedSessions'. This is required when used as a session package.
The session names can be looked up in:
/nix/store/283kp59nkqdvkx6gby2a2c5nivs82v2q-sway-unwrapped-+6816b51/share/xsessions
/nix/store/283kp59nkqdvkx6gby2a2c5nivs82v2q-sway-unwrapped-+6816b51/share/wayland-sessions
Not much you can do but report it to nvidia. Sway/wlroots explicitly do not support the nvidia drivers, nvidia do say they test against sway however. Time to make use of that support you paid for.
I’m back !
I had given up on electron apps when I found this article: NVidia – Hyprland Wiki
This says that electron apps can flicker when using XWayland and that switching to Wayland ozone platform could solve the issue.
My system was already setup to use wayland ozone platform, but just in case I tried to disable it and… It worked. This makes absolutely no sense for me but switching electron apps back to XWayland fixes the issue.
For future reference and if anyone comes here with the same issue, I had to:
Unset the env variable NIXOS_OZONE_WL
Remove the override I had added to google-chrome package to add command line arguments to its executable
I just took what I found on the wiki.