Starting SDDM/KDE Plasma 6 on NVIDIA proprietary driver crashes

[opl-]

Describe the bug

Starting SDDM/KDE Plasma 6 on NVIDIA proprietary driver fails, leaving the user looking at the systemd logs in console mode.

Journal contains the following relevant logs:

sddm-helper-start-wayland[1970]: "kwin_wayland_drm: Failed to create framebuffer: Invalid argument\n"

sddm-helper-start-wayland[1970]: "DRM kernel driver 'nvidia-drm' in use. NVK requires nouveau.\n"

sddm-helper-start-wayland[1970]: "kwin_scene_opengl: failed to import dmabuf KWin::LinuxDmaBufV1ClientBuffer(0x88ac740)\n"
sddm-helper-start-wayland[1970]: "error in client communication (pid 1981)\n"
sddm-helper-start-wayland[1970]: "[destroyed object]: error 7: importing the supplied dmabufs failed\n"
sddm-helper-start-wayland[1970]: "MESA: error: zink: could not create swapchain\n"

Steps To Reproduce

Here's my best guess for the relevant settings:

services.displayManager.sddm.enable = true;
services.displayManager.sddm.wayland.enable = true;
services.desktopManager.plasma6.enable = true;
services.xserver.videoDrivers = [ "nvidia" ];
hardware.nvidia.prime.offload.enable = false;
hardware.nvidia.prime.sync.enable = true;

Expected behavior

SDDM greeter starts and allows logging in to start a Wayland session.

Additional context

The following workaround suggested in this forum thread fixes the issue:

# 24.05
hardware.opengl.package = config.hardware.nvidia.package;
# 24.05 unstable (after #320228)
hardware.graphics.package = config.hardware.nvidia.package;

Perhaps it should be set by the nvidia module if hardware.nvidia.prime.enable is false?

Notify maintainers

@Kiskae

Metadata

$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.9.6, NixOS, 24.11 (Vicuna), 24.11.20240624.2893f56`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.3`
 - nixpkgs: `/nix/store/bi5zxc0v5g6ylygdwyqzh280sccg3ykb-source`

NVIDIA driver version: 550.90.07

---

Add a 👍 reaction to issues you find important.

[opl-]

Realized this comment is obviously an unrelated issue (#311450)

Updating NVIDIA driver to beta 555.52.04 or 555.58 makes the workaround fail again, but in a different way: SDDM does start, but the screen is black with just the cursor, though even it disappears periodically.

Logs include the following:

(udev-worker)[793]: nvidia: Process '/nix/store/agkxax48k35wdmkhmmija2i2sxg8i7ny-bash-5.2p26/bin/bash -c 'mknod -m 666 /dev/nvidiactl c 195 255'' failed with exit code 1.
(udev-worker)[793]: nvidia: Process '/nix/store/agkxax48k35wdmkhmmija2i2sxg8i7ny-bash-5.2p26/bin/bash -c 'for i in $(cat /proc/driver/nvidia/gpus/*/information | grep Minor | cut -d \  -f 4); do mknod -m 666 /dev/nvidia${i} c 195 ${i}; done'' failed with exit code 1.

sddm-helper-start-wayland[1908]: "kwin_wayland_drm: No suitable DRM devices have been found\n"

[Kiskae]

hardware.nvidia.sync.enable = true;

this option does not exist.

NVK requires nouveau.

This does not necessarily indicate an issue. The mesa NVK driver prints that warning on load, even if it is never actually used.

Have you enabled hardware.nvidia.modesetting.enable? When DRM is involved it is required.

[opl-]

this option does not exist.

You're right; corrected it.

Have you enabled hardware.nvidia.modesetting.enable?

I think I tried it without any success, but I tried again anyway. Technically it does improve the situation and allows SDDM and KDE to start, but now I'm hitting other issues.

Using NVIDIA proprietary driver version 555.58 and their closed kernel module on kernel 6.9.7: On the first reboot SDDM froze, on the second reboot KDE froze after ~20 seconds. When I say "froze" I mean the system became so unresponsive even sysrq didn't work.

Since the third reboot SDDM and KDE start correctly, but Firefox keeps crashing within seconds. See table below.

Boot No.	NVIDIA driver version	NVIDIA kernel module	Kernel version	Result
1	555.58	closed	6.9.7	SDDM froze.
2	555.58	closed	6.9.7	KDE froze 20 seconds after logging in.
3	555.58	closed	6.9.7	Firefox crashes.
4	555.58	open	6.9.7	Firefox crashes.
5	555.58	open	6.6.36	Firefox crashes.

[opl-]

On the positive side, it seems the hardware.graphics.package = config.hardware.nvidia.package; workaround is indeed not necessary when hardware.nvidia.modesetting.enable = true;, but only when running the 555.82 NVIDIA driver (kernel 6.6.36). On NVIDIA 550.90.07 (kernel 6.9.7) the issue persists.

As for the other issue, given that after the two initial flukes the system does seem to boot, we should probably move to #311450.

[opl-]

The mesa NVK driver prints that warning on load, even if it is never actually used.

Would it still be logging this? Trying to create a swapchain through zink suggests to me it's not going through NVIDIA.

sddm-helper-start-wayland[1984]: "MESA: error: zink: could not create swapchain\n"

[Kiskae]

The mesa NVK driver prints that warning on load, even if it is never actually used.

Would it still be logging this? Trying to create a swapchain through zink suggests to me it's not going through NVIDIA.

sddm-helper-start-wayland[1984]: "MESA: error: zink: could not create swapchain\n"

No that is a different issue, I believe that indicates SDDM is trying to use vulkan through zink as an opengl provider.

Does it work if you disable PRIME and use just a single driver? Might be related to cross-driver weirdness.

[opl-]

Does it work if you disable PRIME and use just a single driver?

You just made me realize the hardware.nvidia.prime.sync.enable = true; is redundant, as the iGPU is completely unnecessary in this situation.

That said, on NVIDIA 555.58, kernel 6.9.7, nixpkgs b2852eb, removing the workaround once again makes SDDM fail to start with the same errors. With hardware.graphics.package = config.hardware.nvidia.package; it starts working again.

---

In summary, my current config works, and is as follows:

hardware.graphics.package = config.hardware.nvidia.package; # Fixes `MESA: error: zink: could not create swapchain`
hardware.nvidia.modesetting.enable = true; # Fixes SDDM starting with a black screen and a cursor.

boot.kernelPackages = pkgs.linuxPackages_latest;
hardware.nvidia.package = config.boot.kernelPackages.nvidiaPackages.beta; # 555.58 since #322963.
hardware.nvidia.open = true; # Works either way.
hardware.nvidia.prime.offload.enable = false;
services.displayManager.sddm.enable = true;
services.xserver.enable = true; # Probably optional, but I kept it in case Wayland doesn't work.
services.displayManager.sddm.wayland.enable = true;
services.desktopManager.plasma6.enable = true;
programs.xwayland.enable = true;

I also found accidentally stumbled upon this comment, which now allows me to run Firefox without it crashing by running through XWayland with the MOZ_ENABLE_WAYLAND=0 envvar. It's not perfect, as at least hardware video acceleration doesn't work, but it gets me running on the NVIDIA 555.58 driver and gets rid of flickering in Minecraft. Here's the relevant Bugzilla issue tracking the Firefox issue with some PRs submitted 4 days ago.

[DerRockWolf]

From what I can tell the fix will only be included in Firefox 130, the prior versions are all marked with "wontfix"...

[DerRockWolf]

Btw @opl- from what I know services.xserver.enable actually isn't optional on wayland (at least with gnome), the option does way more than enabling the X server 🙂

[pillowtrucker]

is there a separate issue for sddm starting with black screen and cursor ? Turning off hybrid mode with hardware.graphics.package = config.hardware.nvidia.package; is not even really an option in my laptop because of how the various video output ports are wired. This has been happening ever since I upgraded to plasma6. hardware.nvidia.modesetting.enable = true; also doesn't help. Lightdm works fine.
Edit: I guess #311450 is the main issue for that problem, nevermind.

[ccicnce113424]

Only the latest kernels cause this problem. Setting boot.kernelPackage to pkgs.linuxPackages can solve this problem.

[ccicnce113424]

So the problem now is that the nvidia driver does not work with wayland on the latest kernel.

[opl-]

Indeed, hardware.graphics.package = config.hardware.nvidia.package; is no longer necessary for me on Kernel v6.10.11 with NVIDIA proprietary v560.35.03 (current latest/beta as of 3a4ac24).

[fpletz]

Closing this since I believe the issue has been fixed with the recent updates.