Change:
openSha256 = "sha256-/32Zf0dKrofTmPZ3Ratw4vDM7B+OgpC4p7s+RHUjCrg="; settingsSha256 = "sha256-kQsvDgnxis9ANFmwIwB7HX5MkIAcpEEAHc8IBOLdXvk="; persistencedSha256 = "sha256-E2J2wYYyRu7Kc3MMZz/8ZIemcZg68rkzvqEwFAL3fFs="; <ins> patchesOpen = [ fbdev_linux_611_patch ]; </ins> }); beta = selectHighestVersion latest (generic {

Discussion:
I'm encountering an issue with the NVIDIA proprietary drivers when using the latest Linux kernel on NixOS 24.11 (Vicuna) (version: 24.11..). When configured to use the latest kernel (), SDDM fails to start on Wayland and results in a black screen. Occasionally, a frozen cursor appears at a low resolution on top of the black screen, and moving the mouse has no effect. Additionally, when booting with the latest kernel, the system remains stuck on the Plymouth boot screen for a noticeably longer time compared to the stable kernel. A similar issue has been reported in . Steps to reproduce the behavior: the following NixOS configuration: and restart the system. to run SDDM on Wayland or launch a KDE session on Wayland from X11. SDDM and KDE should run on Wayland with the latest Linux kernel and the NVIDIA proprietary driver, without black screen or frozen cursor issues. N/A I have tested both the stable and beta versions of the NVIDIA drivers, as well as using both open and proprietary kernel modules, but the problem persists in all cases. Only reverting to the stable kernel resolves the issue. This issue occurs every time I use the latest kernel. The value in the metadata is set to because I had to run the command from the command-line interface. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Could you use to check your system logs of previous boots to see if there was something related to sddm in there? Unless there is an error logged somewhere I'm not sure where to start looking.
Same issue here, I found workaround trick .
That specifically appears to be about the + errors. The OP issue meanwhile looks like the wayland server and the compositor disagreeing about which drm node is the render node. If the OP still has the issue, I've got some more diagnostics I could use: in the journal related to , looking at similar issues it looks like prints a lot of information about the driver it is using on errors. experiencing the issue, use to go to the virtual console, log in and run to get some information about the current drm nodes 2a. at this point you might want to try to manually restart the GUI and see if it starts working.

I'd like to try this trick, but I am a beginner with NixOS, and I don't know how to apply patches to the open kernel module.
Hi I the kernel params according to to my configuration. And I can confirm that the tty is black (sad) but the desktop environment (kde-wayland for me) works.
I tried it and the result was exactly the same. So this should be an error in the NVIDIA kernel module, unrelated to SDDM, KDE, and KWin.
I created a patch using the following commands from : Then I applied the patch with the following settings: This change did not have any effect; SDDM still does not work properly.
For those looking for a working system until this is fixed without going back too far in kernel versions, pinning to kernel version 6.10.11 resolves the issue for me:
For Linux kernel 6.11, we released a fix in our production branch release 550.120, which uses drmfbdevttmsetup in place of drmfbdevgenericsetup for kernels 6.11 and above. A future release in the new feature branch will contain this fix as well but we do not have a plan to make a release for this branch in the near future. For reference, please feel free to extract production branch release 550.120 and apply the changes to nvidia-drm as you see fit. Our forum post detailing this:
^ when that lands and you still experience the issue, make sure you're using the open driver. The proprietary driver does not get the patch.
I assume this means Pascal (1000 series) and before aren't supported by this patch, since the open modules only support Turing and above, and until nvidia address it in the next major release (565?) are stuck on 6.10 kernels.
You can maybe try to get the patch to apply for the proprietary modules as mentioned in the PR but I didn't want to invest more time. PRs are welcome though. Until then we have to wait for Nvidia to fix it. Note that the production version has been fixed by Nvidia and has been merged into nixpkgs in .