I didn’t see another thread about my exact issues, and at the same time, I still learned a ton from reading the other threads about similar issues. Hopefully sharing my experience will be helpful for someone else, and even better if someone is able to help me resolve the last remaining problems!
My setup:
- Thinkpad P50 with nVidia Quadro M1000M
- Docking station with external monitors
- Fedora 39 (Sway spin)
Some background:
I’ve been limping by with nVidia + Wayland since F38. The major annoyances have been excessive screen flickering, and a complete inability to share my screen in Firefox. Then one of the 6.7.x kernels broke my nVidia drivers completely and I could not compile them at all until nVidia released an update, at which point it worked again for a while.
Then last week I updated to kernel 6.9.4 and started facing issues again, and over the weekend I tried updating to kernel 6.9.5 but that also didn’t fix it. After reading a ton of forums and A LOT of trial and error, I finally found a semi-working configuration.
Here are my observations from the subset of those trials involving kernel 6.9.5 and nVidia 555.52.04 drivers:
555 driver, 6.9.5 kernel, nvidia_drm.modeset=1, multi-user.target → works, but no graphics
555 driver, 6.9.5 kernel, nvidia_drm.modeset=1, nvidia_drm.fbdev=1, multi-user.target → graphics hang before I’m prompted for LUKS password, however… If I type LUKS password, wait a minute, type my login and press enter, then sudo reboot… the machine reboots (proving only the display is hung… the boot process continued)
555 driver, 6.9.5 kernel, nvidia_drm.modeset=1, graphical.target → blank gray screen instead of SDDM login screen (I can change to TTY2 and reboot)
555 driver, 6.9.5 kernel, nvidia_drm.modeset=1, nvidia_drm.fbdev=1, graphical.target → graphics hang before I’m prompted for LUKS password, however… If I type LUKS password, after a minute I reach the graphical login screen and the system works!
Additional Info:
It was necessary to use early KMS, which I configured by setting:
$ cat /etc/dracut.conf.d/nvidia.conf
add_drivers+=" nvidia nvidia_drm nvidia_modeset "
followed by regenerating the initramfs.
I previously had set the nvidia_drm modeset=1 and fbdev=1 options in /etc/modprobe.d/ but after a while it seemed to be no longer working, and so instead I removed that configuration and set:
$ grep CMDLINE /etc/default/grub
GRUB_CMDLINE_LINUX=“resume=/dev/mapper/vg_fedora_mercury-swap rd.luks.uuid=luks-daa3d914-b59a-49c6-956c-e8c66a8818fa rd.lvm.lv=vg_fedora_mercury/root rd.lvm.lv=vg_fedora_mercury/swap rd.driver.blacklist=nouveau nvidia_drm.modeset=1 nvidia_drm.fbdev=1”
followed by updating grub configuration. In retrospect, I’m realizing it’s possible that this was working the same as my current configuration – I simply hadn’t yet realized that the boot process wasn’t really hung, but only the display was. And then because I was just trying to get the thing to boot into multi-user.target, it was a while before I further realized (by accident) that the display actually stops hanging once it reaches graphical.target.
So far, other than the fact that I just have to take it on blind faith that I’m being prompted for my LUKS password without really seeing it, the performance seems much better than before… I don’t think I’ve seen a single screen flicker since I changed to this configuration!
I haven’t yet been able to test screen sharing with Firefox, but will report back once I do. My gut feeling is that it will still be a problem, but I’ll be very happy if I’m wrong about that.