Talk:NVIDIA

nvidia-xconfig

Several of the commands which are suggested to be run with nvidia-xconfig (such as nvidia-xconfig --twinview) don't work with the current nvidia packages in the repository. I just went through setting mine up so I intend to clean up the ones that I can from my experience. Some don't seem to have a 1:1 replacement (there is a --dynamic-twinview argument now; is that the same as --twinview was?). Teh (talk) 13:10, 20 June 2013 (UTC)

While it shouldn't be necessary to use xconfig to get nvidia working on X, creating a 20-nvidia.conf file is an integral step to fix screen tearing for people that suffer from that issue. Perhaps this section should have this explained and include a link to the nvidia troubleshooting article which contains the section about fixing screen tearing? --TheChickenMan (talk) 21:54, 22 December 2016 (UTC)

Troubleshooting sections link to the main documentation, not vice versa. Otherwise there would be no point in having separate troubleshooting sections. -- Lahwaacz (talk) 22:03, 22 December 2016 (UTC)

Compositing

I think it could be helpful for anyone that's still using X server to be guided on setting up compositing.

One way to update the Xorg.conf file to enable composition is to use the nvidia command line tool:

   # nvidia-xconfig --composite

The other is to edit the file manually, as per the example below adding the Composite Option to the Extensions section of /etc/X11/xorg.conf:

   Section "Extensions"
       Option         "Composite" "Enable"
   EndSection

For those running KDE, to check if compositing is enabled they can run the following command, compositing information is at the end of the output:

   $ qdbus org.kde.KWin /KWin supportInformation

Esdaniel (talk) 06:25, 16 October 2017 (UTC)

Driver manual links become outdated

There is a lot of valuable information in the official manual for Nvidia's proprietary graphics drivers, but any links to them have the driver version hardcoded, e.g. https://download.nvidia.com/XFree86/Linux-x86_64/510.47.03/README/. As such, over time these pages have accumulated a lot of different driver versions, generally without the intent of wanting to link to that particular version. In the short term, these should probably be manually updated, since some of them are way back in the 3xx drivers. In the longer term, though, it might be nice to setup a site that redirects to the latest driver manual. Nvidia provides https://download.nvidia.com/XFree86/Linux-x86_64/latest.txt which has the version, but it seems there is no URL that directly leads to the correct directory. Cheers, CodingKoopa (talk) 06:05, 2 May 2022 (UTC)

I agree that a static link would be good. But I guess Nvidia does not even have such a link themselves, as they always create new forum entries. So a local solution is probably "necessary".

As these discussion pages don't get answers by the Arch admins very often, I would suggest that you could try to reach them directly, whether such a technology is already available or if they would be interested implementing it.

Otherwise I think that Arch users should be able to identify their drivers version and look up the correct manual themselves.

G3ro (talk) 18:29, 2 May 2022 (UTC)

I've checked quickly: there are 7 places which use a versioned link.

The links in NVIDIA#Installation and NVIDIA#Manual configuration should indeed be updated at every new release if we want keep things coherent.

The three links to the legacy drivers in NVIDIA#Unsupported drivers can become outdated without the information becoming irrelevant, since it's only there for the list of supported hardware, which will not change with a point release of these branches.

Same for the one in NVIDIA#Enabling SLI, it's mainly used as a reference for the citation on what is a supported configuration for SLI.

The last one is on NVIDIA#TwinView and will probably be fine too, since this way of supporting multi-monitor is on it's way out.

If someone has the coding skills to auto-update this page when needed, I doubt objections will be raised. Looks like the source for wiki-scripts is open for anyone 😉. --Erus Iluvatar (talk) 19:42, 2 May 2022 (UTC)

I've updated NVIDIA#Installation and NVIDIA#Unsupported drivers to point to nouveau's wiki, so there are only the links in NVIDIA#Manual configuration, NVIDIA#Enabling SLI and NVIDIA#TwinView left on the list. --Erus Iluvatar (talk) 10:34, 11 May 2022 (UTC)

Unable to login on VTs after following Installation: Step 5 (remove kms from hooks then regenerate initramfs)

After a fresh install, following this step (remove kms from hooks and regenerate initramfs) caused me to lose access to login on all VTs except VT1 on the next reboot. Luckily my display manager (running on VT1) still worked and allowed me to login.

Looking into this, I found that simply regenerating the initramfs at least once after installing the nvidia package is enough, no need to remove the kms hook. Although this will still copy the 'nouveau' kernel module to the initramfs, it will also pull in /usr/lib/modprobe.d/nvidia-utils.conf, which will blacklist the module and prevent it from loading. Ackalker (talk) 17:02, 15 April 2023 (UTC)

And then the next time you regenrate it, it's going to inexplicably balloon in size. That also requires checking to make sure the modconf hook is there, so you're still going to be in that file.

As far as the VT issue, having the module but blacklisting it or not having the module shouldn't make any difference.

Scimmia (talk) 17:58, 15 April 2023 (UTC)

Framebuffer consoles experimental support

From 545.29 release [1]:

Added experimental support for framebuffer consoles provided by nvidia-drm. On kernels that implement drm_fbdev_generic_setup and drm_aperture_remove_conflicting_pci_framebuffers, nvidia-drm will install a framebuffer console when loaded with both `modeset=1` and `fbdev=1` kernel module parameters. This will replace the Linux boot console driven by a system framebuffer driver such as efifb or vesafb. Note that when an nvidia-drm framebuffer console is enabled, unloading nvidia-drm will cause the screen to turn off.

Maybe this should be mentionned in NVIDIA#DRM_kernel_mode_setting or NVIDIA/Tips and tricks#Fixing terminal resolution? SirDelajolie (talk) 06:52, 5 November 2023 (UTC)

`fbdev=1` seems to cause my display to freeze (tty cursor not flickering, typed letters not appearing, etc., while Ctrl + Alt + Delete still works.)

Both passing it as a kernel param, or on module load cause this effect.

This is from a 1060 (Pascal). Dexus (talk) 19:57, 28 December 2023 (UTC)

If it is freezing when you enable fbdev=1, you need to add the nvidia modules to your initramfs like it says in the NVIDIA#Early loading section and then move both the modeset and fbdev parameters out of modprobe.d and into your kernel arguments in your bootloader config. Without putting the modules into initramfs, fbdev=1 will cause the screen to freeze. If you keep the module parameters int modprobe.d, fbdev=1 will fail to take into effect. UrbenLegend (talk) 07:19, 25 March 2024 (UTC)

FWIW, I am running the stable 555.58.02-10 driver on kernel 6.10.2.arch1-1 (without nvida-utils). I have the modeset and fbdev kernel parameters set via modprobe.d and I have no issues (and a high res console). Apparently, the nvidia-utils package does some wonky things that mess with the base driver. Unfortunately, I am probably going to have to install the nvidia-utils package since I'm using fbdev, thus I need framebuffer persistence (i.e. nvidia-suspend and nvidia-resume). I thought those were only really required with GDM but, alas no, SDDM needs them too. Eagerestwolf (talk) 15:28, 31 July 2024 (UTC)

Correction. I do have nvidia-utils installed. I was running the wrong pacman command...oops (I should have known that since nvidia requires nvidia-utils). Eagerestwolf (talk) 15:31, 31 July 2024 (UTC)

I've added a notice as someone in the Telegram group had yet another issue where external screen wouldn't work due to this issue C0rn3j (talk) 18:04, 1 January 2024 (UTC)

I think this section of the article have the reference to `fbdev=1` changed to mention it as an optional, experimental feature further down in the paragraph. Reading over it, the article makes it sound like it's a requirement to be enabled despite the fact that the current Arch kernels (linux, linux-lts and linux-zen that I can see, possibly others) have the custom patch to disable `simpledrm` if `modeset=1` is enabled, making the experimental `fbdev=1` parameter unnecessary? I am happy to re-write it as such if everyone else agrees. G33KY (talk) 18:28, 14 January 2024 (UTC)

The kernel patch was a hack, and it changes the behavior of nvidia-drm.modeset=1 when set through kernel cmdline, but not when using modprobe.d. I'd rather avoid such inconsistency. -- YHNdnzj (talk) 10:56, 15 January 2024 (UTC)

I just think the article in it's current incarnation is a bit confusing with regards to it. I'm using NVIDIA 545.29 without `fbdev=1` (I haven't changed it since 2022) and it's working fine due to the kernel hack, I don't see the point in having the hack if the wiki says to not use it? As NVIDIA have mentioned the fbdev driver is experimental and others have said that it's flaky for them (with a big warning tag on the article), so I think it would make more sense to have an explanation that there are two options the user can choose: option a) use kernel parameter and the kernel hack (for as long as the Arch kernels build that hack), or option b) use the kernel module parameter with the experimental driver. This will give the user a choice rather than the currently confusing explanation which tells them they must use a module parameter while that same module parameter has a big red "caution" tag right above it. G33KY (talk) 17:20, 15 January 2024 (UTC)

For me, using this patch from nvidia fixed some of my issues, they were related to detecting multiple monitors. It is somewhate related to hotplugging. Mb` (talk) 03:56, 22 January 2024 (UTC)

NVIDIA has released the 550.40.07 beta drivers; it mentions fixing fbdev=1 causing flip timouts. Dexus (talk) 21:03, 24 January 2024 (UTC)

Just for the sake of recording this, I've found that setting fbdev=1 on my system causes udev events to not be sent upon hotplugging my laptop's external HDMI port. I was relying on a udev rule to trigger autorandr, so this issue manifested as my DE failing to extend to an external display upon connecting to it. LRitzdorf (talk) 18:12, 18 January 2024 (UTC)

Update: as of this writing, setting fbdev also does weird things to udev, causing it to not properly activate RTD3 power management when using the PRIME article's RTD3 udev rules. This confused me for quite a while, grr. LRitzdorf (talk) 02:23, 22 August 2024 (UTC)

I rewrote the KMS section, including fixing the writing issues regarding fbdev confusion. I suppose it will need further edits when 550 releases outside of beta, to either note persisting issues or that it did indeed is a solid experimental implementation now. C0rn3j (talk) 12:27, 7 February 2024 (UTC)

Time has passed. fbdev is now on by default in Arch and Nvidia is planning on turning it on by default upstream too, so this thread should be resolved now. C0rn3j (talk) 16:03, 13 October 2024 (UTC)

Should Explicit Sync be mentioned?

Starting from the 555.42.02 version, NVIDIA supports Wayland explicit sync which in my case helps massively with frame jumps/skipping/stuttering. I believe (X)Wayland 24.1+ is needed, however NVIDIA's README from the same driver version says that XWayland has issues due to no syncing mechanism provided [2] , and I'm not sure if that is still true, refers to something else entirely, or was written before linux-drm-syncobj-v1 was released with 24.1 and just wasn't updated. Latenight.bread! (talk) 12:01, 27 May 2024 (UTC)

It is relevant for both Wayland and Xwayland, ES fixes both, I have added a note.

C0rn3j (talk) 16:01, 13 October 2024 (UTC)

The sane defaults.

Maybe I am way off here and I do want people to correct me if this is the case. Having said that, I believe that there should be a note or a tip somewhere explaining that for most users (especially laptop users), installing the nvidia driver (be it nvidia-open, nvidia-open-dkms, or nvidia, nvdia-lts, nvidia-dkms) should be enough. There is a lot of confusion on how to do GPU offloading, something that these drivers do by default at this point. We do mention in the PRIME article that this method is officially supported but nowhere is it mentioned that by default nvidia drivers turn off your card when it is not needed, driving people to experiment with outdated and unstable solutions like optimus-manager (optimus is not really unstable, but python is and by proxy people do encounter black screens when using optimus).

Basically I strongly believe that we should strive to recommend some "sane-defaults for average users" and in this aspect, there are really only two outliers with nvidia:

1. Install the driver and do nothing else. The default behavior is turning off your dGPU when it is not needed (for example if you are on a laptop without any external monitors connected - at least not directly on your dGPU) and turning it on when applications ask for it, for example when gaming.
2. If you are on a desktop computer and you really want performance and more options out of nvidia-settings, disable your iGPU completely.

There are tons of people that, after not having been given any short of direction here turn to outdated videos, articles etc from third parties that recommend solutions that are not needed anymore and that will create far more issues that they will solve. Bottom line, I strongly believe that we need to protect the users from this kind of thing when possible, and in this case it is absolutely possible at this point. SKaraferias (talk) 23:50, 22 January 2025 (UTC)

One more thing I really need to add here is that 3rd party apps like optimus, bumblebee etc, are hard to wipe of your system if you are a new user and don't know where to look, so they should be implemented with care and maybe we should provide more guidance on how to remove them if needed. SKaraferias (talk) 23:55, 22 January 2025 (UTC)

Recommending to do nothing else does not make sense. If there are objective issues with some solutions, feel free to add warnings to the appropriate places. Also note that it should be done on pages like PRIME and NVIDIA Optimus, not here. — Lahwaacz (talk) 06:36, 23 January 2025 (UTC)

I agree that it should be done in Prime or NVIDIA Optimus, that was bad judgement on my part. Furthermore, maybe I did not express myself correctly, but I am not suggesting that we should say to people that they should not do anything else. We should make people aware that the solution that is supported by NVIDIA (prime offload) is already implemented in the driver they installed. So anything else they do, they are adding on top of that. For example, optimus manager's hybrid setting is at this point the exact same with the default behavior of the drivers. I don't know if warnings here and there are the correcct medium to express that. I believe a tip in the PRIME page or in the NVIDIA Optimus page would be better. Basically it is not explained, anywhere in the wiki, what the default behavior of the driver that we suggest people should install, is. SKaraferias (talk) 13:59, 23 January 2025 (UTC)

So basically PRIME#PRIME render offload says exactly this. — Lahwaacz (talk) 10:44, 25 January 2025 (UTC)

Some important steps may be overlooked

I was lead away from doing the important parts of this section by the line in the prior section saying "Once the driver has been installed, continue to #Xorg configuration or #Wayland configuration." Although I didn't need to do 1.1, I did need to do 1.2 and update initramfs by changing the MODULES line to MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm) and removing kms from the HOOKS line in /etc/mkinitcpio.conf,then running `mkinitcpio -P`, and then since I'm using GRUB, I needed to add `nvidia_drm.modeset=1 nvidia_drm.fbdev=1 nouveau.blacklist=1` inside the quotes of the GRUB_CMDLINE_LINUX_DEFAULT line in the /etc/default/grub file and running `grub-mkconfig -o /boot/grub/grub.cfg` before running `nvidia-xconfig` in section 3. So... a few suggestions:

1. Remove the confusing line so people don't skip section 1.

2. Add a test at the start of section 1.1 to verify if people need to do anything there

3. Simplify the instructions for 1.1 to directly indicate which files need editing and what the lines in those files should look like. e.g. "edit /etc/mkinitcpio.conf and add 'nvidia nvidia_modeset nvidia_uvm nvidia_drm' in the () on the MODULES= line, then remove 'kms' from the HOOKS= line. then run `mkinitcpio -P`

4. The part about updating GRUB is more difficult, and I'm not sure how to improve that without causing issues.

I'm new, so I don't feel comfortable making those changes on my own. Your feedback / improvements / encouragement is welcome. --JamesNewton (talk) 19:48, 16 May 2025 (UTC)

Why did you need to do this? Everything works well on my PC without these steps. — andreymal (talk) 20:16, 16 May 2025 (UTC)

Regarding this, for 1) it was needed specifically for a case of the legacy nvidia-390xx-dkms drivers, but I've seen other users require early KMS to prevent edge cases where the display manager starts before the nvidia module loads for X11. Given it's a requirement for wayland and some X11 cases, maybe it could be mentioned to consider configuring early loading before proceeding to X11 configuration or wayland configuration?

For 2/section 1.1, new users may not know if if they're running a customer kernel, so having them check uname -r and pacman -Q|grep linux '<output of uname -r>' will have them verify if they need to proceed with 1.1

For 3/section 1.2.1, maybe just a small note that mkinitcpio is the default initramfs generator per the install guide so as to not confuse new users

For 4/section 1.2, the user was instructed to do it via boot loader kernel parameters as it required less steps / made it more clear those module options were being directly set, so maybe that bit should read 'set the nvidia-drm.modeset=1 option via the bootloader or modprobe.d config in the initramfs (see link)' instead of ' set the modeset=1 kernel module parameter for the nvidia_drm module.' G-ramirez (talk) 21:54, 16 May 2025 (UTC)

1 - early loading is not a requirement for Wayland

2/1.1 - users always know what they have installed themselves

3/1.2.1 - this is already mentioned in Installation guide#Initramfs, so users always know what initramfs generator they use

4/1.2 - there is no need to duplicate the Kernel module#Setting module options section, and the wiki should not force users to use only one of available options

So the NVIDIA page is good enough as it is.

— andreymal (talk) 22:20, 16 May 2025 (UTC)

Force DPI on Xorg in monitor section

Since nvidia version 580.82.09-2, (might also be case on few version prior) I had to force DPI in

/etc/X11/xorg.conf

Section "Monitor"
    ...
    ...
    Option         "DPI" "96 x 96"
    Option         "UseEdidDpi" "FALSE

96 x 96 DPI being the default DPI, and EDID being Extended Display Identification Data, that should be able to read info from monitor.

Otherwise i3 would have Fonts and elements 3 times bigger. Pulec (talk) 02:23, 20 September 2025 (UTC)