Nvidia and Linux: is this marriage bad?

ricky89 · January 11, 2025, 12:54pm

My last videocards since 2011 was Nvidia based cards: I owned gtx 560, gtx 960, gtx 1060, rtx 2060super, and now by august 2023 on my main setup I own a rtx 3070ti.

I tried to use most of thems under Windows and under Linux. Under Windows there’s absolutely no problems, drivers are unique and official released by mother company. But under Linux?

Nvidia cards drivers were official released by Nvidia on Linux since 1999, so for long period until now. They were always closed propretary code, and only by 2022 Nvidia start releasing Nvidia kernel modules under GPL license.

For what I have to say and for my experience I remember a couple of times I was trying to install official Nvidia drivers on Linux, and for doing that it’s a bit tricky because before installing Nvidia package, you need to blacklist noeveau, the default graphic module in Linux kernel.

Since when Nvidia modules where open source relesed I would say it becomes so easy install Nvidia drivers in every distribution: I tried Arch and some Ubuntu derivates, the process is the same on each distribution. Once installed the base system, go in official distribution repositories and download Nvidia driver relative at your hardware. Et voila! They will run flawless without any problems.

For my experience I had a problem with Nvidia drivers and Debian 12 bookworm, because once installed the base system I was stuck in a black screen. How I resolved this? Simple! I logged in a rescue terminal and I downloaded Nvidia drivers from official Debian repositories. How it went? Everything went fine after installing the corresponding Nvidia drivers.

I have to say until 1 year ago I was using Nvidia Surround functionality offered natively by Nvidia drivers running under Windows where you can use 2 or more monitors for obtaing a single big monitors, for a complete videogames or multimedia immersion.

So, excited, I bought 2 equals 1080p at 75hz monitors by MSI, very decent monitors. But sadly I was not able to enjoy Nvidia surrond on Linux, because I found Nvidia surround development is still nowdays so immature. Maybe in future? Who knows.

A point that make me difficult decision from using Windows or Linux as primary computer was also this, but I was enjoying more gaming under Linux. So?

After understanding this, and as I want to continue my Linux journey, I bought a 144hz curve monitor, 32 inches and 3440x1440 resolution, for enjoy ultrawide gaming experience on a single monitor. Now on my daily computer I have 2 monitors setup, one 32’’ ultrawide and one 27’’ 1080p. The problem I had on Linux is that fullscreen games on primary monitor with a different refresh rate from other monitor will run at maximum refresh rate of the second monitor. So on my 144hz monitor I was playing videogames at 75fps. I asked in a local Italian Linux community and they said me “you can’t do it, Nvidia drivers can’t support it”. Is it really true? So I went deeply and I discovered these guys were wrong, since I found a very good documentation on reddit:

https://www.reddit.com/r/linuxhardware/comments/mht7kn/workaround_for_multiple_monitors_with_different/?rdt=33618

The steps I followed were those:

add __GL_SYNC_DISPLAY_DEVICE=DP-0 at the end of /etc/environment (modify DP-0 with your current primary monitor on your setup, you can get the string with xrandr)
run nvidia-settings, go to OpenGL Settings and uncheck Allow Flipping

2025-01-11_13-24870×554 94.7 KB
create a custom sh file containg those lines:

#!/bin/bash
nvidia-settings --load-config-only &

make sure to launch this script at system startup (in XFCE it’s so easy do it)
reboot the machine

After followed these steps it works like a charm, I was able to run natively 144hz videogames in ultrawide primary monitor, and the second monitor was running at 75hz, it’s default refresh rate.

Now I know it’s a little tricky/specific behaviour, but someone it might be useful follow this guideline.

In conclusion I want to say Nvidia marriage in Linux nowdays is not so bad, drivers are present in most distribution repositories, and in some cases, for example in POP!_OS, Nvidia drivers are natively builted into distribution iso, so install the system and run it without any kind of problem.

The same for Nvidia modules, they are released for any modern kernel, you might found some mismatch headers version, but in general, if you stuck with distribution repository mainline release, there will always compatibility with Nvidia cards in latest kernel, even in some LTS releases.

toadie · January 12, 2025, 9:45am

I think the bad reputation of Nvidia under Linux is not justified.

At least I never had a real problem. Always Intel+Nvidia.
Whether under Arch, Xubuntu, Linux Mint or openSUSE. Whether back in 2010 or today.
Maybe just luck?

IronRod · January 12, 2025, 4:48pm

I’ve had a generally good experience using the NVidia driver; certainly no severe issues like a black screen, etc. (Currently running a GTX 1660 Super with LinuxMint 22 and a 2560x1440 display.) Yet, I am experiencing a minor issue at the moment; kind of a weird one, too. Everything was perfect with the current 550 Nvidia driver and then I received the 6.8.0-50 kernel update.

Normally, during boot, I see the circular LM logo for a few seconds then get the login screen. With the new kernel, this changed to the logo zoomed twice as large and no longer circular but oval, stretched horizontally. After about a second the display blinks and the logo goes circular but remains twice as large. After the login screen appears things seem normal – except, further investigation reveals what seems still an issue. Under the 6.8.0-49 kernel – when everything works perfectly – inxi -G reports this:

Graphics:
  Device-1: NVIDIA TU116 [GeForce GTX 1660 SUPER] driver: nvidia v: 550.120
  Device-2: Logitech QuickCam Pro 9000 driver: snd-usb-audio,uvcvideo
    type: USB
  Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.6 driver: X:
    loaded: nvidia unloaded: fbdev,modesetting,nouveau,vesa
    gpu: nvidia,nvidia-nvswitch resolution: 2560x1440~120Hz
  API: EGL v: 1.5 drivers: nvidia,swrast
    platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 550.120
    renderer: NVIDIA GeForce GTX 1660 SUPER/PCIe/SSE2
  API: Vulkan v: 1.3.275 drivers: N/A surfaces: xcb,xlib

With the 6.8.0-50 kernel, inxi -G reports this:

Graphics:
  Device-1: NVIDIA TU116 [GeForce GTX 1660 SUPER] driver: nvidia v: 550.120
  Device-2: Logitech QuickCam Pro 9000 driver: snd-usb-audio,uvcvideo
    type: USB
  Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.6 driver: X:
    loaded: nouveau unloaded: fbdev,modesetting,vesa failed: nvidia
    gpu: nvidia,nvidia-nvswitch resolution: 2560x1440~120Hz
  API: EGL v: 1.5 drivers: kms_swrast,nvidia,swrast
    platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 550.120
    renderer: NVIDIA GeForce GTX 1660 SUPER/PCIe/SSE2

Note the difference in the Display line – showing loaded: nvidia vs failed: nvidia and there is no API: Vulkan

Yet, interestingly, I have previously noted a distinct difference in graphics quality between running the nouveau vs nvidia driver (noticeable when streaming or viewing videos) so that I know that it is using the nvidia driver. At least, visually, it appears so.

Researching the issue, I’ve found articles reporting similar (but not the same behavior) so I’m hopeful a new driver version will resolve this. For now, I’ve actually reverted back and keeping with the 6.8.0-49 kernel to avoid this issue. Suggestions are welcome. I’ve posted on this issue in the LinuxMint forum here and here but no resolution.

toadie · January 12, 2025, 9:06pm

Maybe the Kernel is to old?

Noproblems here with Kernel Linux 6.12.8-1-cachyos, but on Arch the rules are a bit different than under Mint

Graphics:
  Device-1: NVIDIA GM107 [GeForce GTX 750] driver: nvidia v: 565.77
  Display: wayland server: X.org v: 1.21.1.15 with: Xwayland v: 24.1.4
    compositors: 1: kwin_wayland 2: Tabby driver: X: loaded: nvidia
    unloaded: modesetting gpu: nvidia resolution: 3440x1440
  API: EGL v: 1.5 drivers: nvidia
    platforms: gbm,wayland,x11,surfaceless,device
  API: OpenGL v: 4.6.0 vendor: nvidia v: 565.77 renderer: NVIDIA GeForce
    GTX 750/PCIe/SSE2
  API: Vulkan v: 1.4.303 drivers: N/A surfaces: xcb,xlib,wayland

ricky89 · January 13, 2025, 12:10pm

@toadie …Maybe just luck or maybe you did not went deep enough (:
jokes apart, I had some small issues with Nvidia cards, as I posted, but I was able to fix everything. The drivers always works fine for me since 2019 when I started my Linux journey, and I never had a kernel incompatibility.
This also because I always stay with latest kernel version, also in Debian I was using bleeding edges kernel. On Debian testing release Nvidia drivers with latest kernel is working like a charm. The same I would say it’s the same on Arch with latest updates.

@IronRod that’s very odd, it seems for some reason the system isn’t able to load propretary Nvidia drivers and it’s stuck with default nouveau.
That would explain the different looking of the different graphic quality, but are you able to start some game with wine + vulkan? Or some applications running Opengl? In theory if propretary driver isn’t loaded I think you might see a popup sayng some errors.

I can tell you I was on Linux Mint during summer 2024, I can’t remember which version of Nvidia driver, but for sure I never had some issues.

Btw Driver 550.120 were officially released by Nvidia at september 2024:

Linux Mint is using so old packages, my hypothesis is latest kernel available on Linux Mint might be a bit buggy with Nvidia drivers, expecially oldest one. that’s very unlucky for you (:

I don’t have the answer I never was into this problem, but I can suggest you this reddit I found googling:

The user might have a Nvidia card problem similar yours, I suggest you to keep monitored the thread and the situation, Btw I’m pretty sure there will be a fix, although Linux Mint is’t so fast on updates you might wait for a while.

Or… if you are brave enough you can try download Nvidia drivers from official website and install them…

IronRod · January 13, 2025, 9:35pm

@ricky89 Actually, yes. Everything seems to work fine after I log in. The only visual manifestation is the boot logo issue I mentioned. I have Steam running and installed on this system with no issues there. For each game, the shaders are downloaded and appear to work fine.

The system is currently on the 550.120 driver. That is the current one LM22 is providing. I looked at the Nvidia site yesterday and see that 550.142 is now available. I may give downloading and installing that a try to just see what happens.

The strange part is this: Other than the boot logo issue, everything appears to be running fine and as if it was running Nvidia not nouveau. If I install the nouveau driver, I can definitely see a difference: streaming is worse and jumpy, not smooth. This is why I’ve always gone with the Nvidia driver. So, in this case, what I see is very smooth streaming just as if the Nvidia driver was working. Checking Driver Manager under LinuxMint, it certainly shows Nvidia 550.120 as the installed driver but, clearly, something is happening during boot (with the 6.8.0-50+ kernel) that is causing Nvidia to show as failed and nouveau as loaded. But the visual result appears the same as if Nvidia were loaded and running. And with the 6.8.0-49 kernel, it loads Nvidia fine with no issues at all.

So, do the LM maintainers just accept the kernel builds provided by Ubunutu, I think?

There seem to be a number of issues related to Nvidia drivers on the 6.8.0-50+ kernel. When I search for “issues with nvidia driver and 6.8.0-50 kernel” a number of items pop up. It might just have to wait until the 560 Nvidia driver comes out.

So, this was interesting…

I just found a page on installing Nvidia drivers manually on LM22. This was very informative and I learned a bit.

From the Nvidia site the latest driver for my GeForce GTX 1660 Super is the 550.142 driver. So, I downloaded it and went through the process to install. (NOTE: In the article, it is loading the 560 driver. I guess I may need to upgrade my venerable and still very usable 1660 Super if I want to use any new drivers.)

Sadly, after the final reboot, the boot logo issue remains. It annoys me but livable, I guess, if things are working fine. I saw this from inxi -G:

Graphics:
  Device-1: NVIDIA TU116 [GeForce GTX 1660 SUPER] driver: nvidia v: 550.142
  Device-2: Logitech QuickCam Pro 9000 driver: snd-usb-audio,uvcvideo
    type: USB
  Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.6 driver: X:
    loaded: nvidia gpu: nvidia,nvidia-nvswitch resolution: 2560x1440~120Hz
  API: EGL v: 1.5 drivers: nvidia,swrast
    platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 550.142
    renderer: NVIDIA GeForce GTX 1660 SUPER/PCIe/SSE2

Note that it doesn’t even show the noveau driver. I suspected that was because of the blacklist additions applied in the article. So, I commented those out, and rebooted. After it still has the logo issue but inxi -G now is back to showing failed: nvidia:

Graphics:
  Device-1: NVIDIA TU116 [GeForce GTX 1660 SUPER] driver: nouveau v: kernel
  Device-2: Logitech QuickCam Pro 9000 driver: snd-usb-audio,uvcvideo
    type: USB
  Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.6 driver: X:
    loaded: modesetting unloaded: fbdev,vesa failed: nvidia dri: nouveau
    gpu: nouveau resolution: 2560x1440~120Hz
  API: EGL v: 1.5 drivers: nouveau,swrast platforms: x11,surfaceless,device
  API: OpenGL v: 4.5 compat-v: 4.3 vendor: mesa v: 24.0.9-0ubuntu0.3
    renderer: NV168

And it shows loaded: modesetting rather than nouveau even though, with nouveau blacklisted, it showed loaded: nvidia. So, with nouveau blacklisted, it could only find nvidia, so it loaded it anyway?

hydn · January 14, 2025, 12:08pm

You know, back when I used NVIDIA GPUs—strictly AMD now, from the MB, CPU to CPU—I remember Manjaro taking care of this using their hardware configuration tool.

Which looks something like this:

I am not sure if it’s still like this?:

Have not used Manjaro in a long time. But it made GPU setup pretty simple.

IronRod · January 14, 2025, 5:47pm

Further researching, I also noticed that the Device-1 (the graphics GPU) shows driver: nvidia while the Display: shows 'loaded: nouveau. This seemed odd and, researching further, found that this means that the driver was loaded successfully for the GPU but that the X server failed loaded nvidia and fellback to nouveau.

So, I blacklisted nouveau and forced nvidia by doing the following (from the previously referenced page on installing Nvidia drivers):

echo "blacklist nouveau" >> /etc/modprobe.d/blacklist-nouveua.conf
echo "options nvidia NVreg_PreserveVideoMemoryAllocations=1" >> /etc/modprobe.d/nvidia.conf
echo "options nvidia-drm modeset=1 fbdev=1" >> /etc/modprobe.d/nvidia.conf
update-initramfs -c -k $(uname -r)
reboot

Now inxi -Gx shows both the Device and the Display using nvidia:

Graphics:
  Device-1: NVIDIA TU116 [GeForce GTX 1660 SUPER] vendor: ASUSTeK
    driver: nvidia v: 550.120 arch: Turing bus-ID: 07:00.0
  Device-2: Logitech QuickCam Pro 9000 driver: snd-usb-audio,uvcvideo
    type: USB bus-ID: 1-6.3:4
  Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.6 driver: X:
    loaded: nvidia unloaded: fbdev,modesetting,nouveau,vesa
    gpu: nvidia,nvidia-nvswitch resolution: 2560x1440~120Hz
  API: EGL v: 1.5 drivers: nvidia,swrast platforms:
    active: gbm,x11,surfaceless,device inactive: wayland,device-1
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 550.120
    glx-v: 1.4 direct-render: yes renderer: NVIDIA GeForce GTX 1660
    SUPER/PCIe/SSE2

But: I still have the weird boot logo issue. So, this means that, once booted, it is using nvidia (appears to be the case) but during boot – before the desktop displays – there is still some issue, right? (Maybe this isn’t important but it feels like my system is broken and I hate broken systems. Don’t we all?)

devdev · January 21, 2025, 2:17pm

You’ve made solid progress ensuring the system uses the NVIDIA driver properly after boot—great work! The boot logo issue is likely related to how the framebuffer is handled early in the boot process. While it doesn’t affect performance, I get how frustrating it can feel.

Here are a few quick tips to resolve it:

Update GRUB Settings: Add this to /etc/default/grub:
```
GRUB_GFXMODE=1920x1080
GRUB_GFXPAYLOAD_LINUX=keep
```
Then run sudo update-grub.
Rebuild Initramfs: Ensure the nvidia modules are loaded early:
```
MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)
```
Then update with sudo update-initramfs -u. (For Arch: sudo mkinitcpio -P.)

Check Plymouth (if used): Reconfigure the splash screen:

sudo plymouth-set-default-theme <your_theme>
sudo update-initramfs -u

Kernel Boot Params: Ensure nvidia-drm.modeset=1 is in the GRUB_CMDLINE_LINUX_DEFAULT.

Let us know.

IronRod · January 22, 2025, 5:46pm

Thanks for that info. Before I try those – some will be a second attempt – let me share this for consideration: The really odd thing to me is that this behavior seems to not be related to the grub config though it appears during boot. This is a multi-boot system which has a “LM22” LM22.1 partition, a “LM22_test” LM22.1 partition, and a “Windows” Win11 partition. At this time, the boot target is the “LM22” partition. (I understand that it is the grub entries on the boot target partition which determine the grub menu displayed, etc.) Yet, from the grub menu, when I select the “LM22” instance – which runs the 6.8.0-49 kernel – I do not see the logo anomalies. If, from the grub menu, I select the “LM22_test” instance – which runs the 6.8.0-50 kernel – it then displays the described anomalies. If I change the boot target to the “LM22_test” instance (so that it is using that grub configuration), the behavior is exactly the same. That tells me that it isn’t really grub that is at fault? Or am I missing something? The only significant difference between “LM22” and “LM22_test” is the kernel being used. (I keep these two nearly identical at a system level, using “LM22_test” for the purpose of trying things out before I decide to apply them to “LM22”.)

IronRod · January 31, 2025, 6:47pm

I’m still digging into this… . While correcting this issue may not warrant all this effort, I am using it to really understand more about my system and, in particular, what is going on here.

Thanks @devdev for your ideas. My system has plymouth but no plymouth-set-default-theme is found. Changing the grub settings didn’t have an effect – but, based upon my earlier thoughts, I didn’t expect that it would.

Please check my thinking:

The UEFI firmware boots the EFI bootloader which reads /boot/efi/EFI/ubuntu/grub.cfg which points to /boot/grub/grub.cfg and it then displays the grub menu. The grub menu is then displayed and I can select from any of the listed bootable partitions.
It is only after selecting an entry from the grub menu that the logo appears – displaying small if I select the partition running the 6.8.0-49 kernel or large and ovoid if I select the partition running the 6.8.0-50+ kernel.
So, if this occurs after I select the partition to boot, isn’t then the resulting issue manifested by the subsequent boot of Linux and not of grub? If so, then it seems I am into initrd, right? Not grub?

lsinitramfs shows that nvidia is being loaded (I think) on the kernel 49 system:

$ lsinitramfs /boot/initrd.img-$(uname -r) | grep nvidia
usr/lib/modules/6.8.0-49-generic/kernel/drivers/hid/hid-nvidia-shield.ko.zst
usr/lib/modules/6.8.0-49-generic/kernel/drivers/net/ethernet/nvidia
usr/lib/modules/6.8.0-49-generic/kernel/drivers/net/ethernet/nvidia/forcedeth.ko.zst
usr/lib/modules/6.8.0-49-generic/kernel/drivers/usb/typec/altmodes/typec_nvidia.ko.zst
etc/modprobe.d/blacklist_i2c-nvidia-gpu.conf
etc/modprobe.d/nvidia-graphics-drivers-kms.conf
scripts/casper-bottom/56override_nvidia_udev_rule
usr/lib/modprobe.d/nvidia-graphics-drivers.conf

And on the (now) kernel-51 system:

$ lsinitramfs /boot/initrd.img-$(uname -r) | grep nvidia
usr/lib/modules/6.8.0-51-generic/kernel/drivers/hid/hid-nvidia-shield.ko.zst
usr/lib/modules/6.8.0-51-generic/kernel/drivers/net/ethernet/nvidia
usr/lib/modules/6.8.0-51-generic/kernel/drivers/net/ethernet/nvidia/forcedeth.ko.zst
usr/lib/modules/6.8.0-51-generic/kernel/drivers/usb/typec/altmodes/typec_nvidia.ko.zst
etc/modprobe.d/blacklist_i2c-nvidia-gpu.conf
etc/modprobe.d/nvidia-graphics-drivers-kms.conf
etc/modprobe.d/nvidia.conf
scripts/casper-bottom/56override_nvidia_udev_rule
usr/lib/modprobe.d/nvidia-graphics-drivers.conf

The only difference appears to be that the kernel-51 system loads the additional file etc/modprobe.d/nvidia.conf which I created earlier to enforce the options:

$ cat /etc/modprobe.d/nvidia.conf
options nvidia NVreg_PreserveVideoMemoryAllocations=1
options nvidia-drm modeset=1 fbdev=1