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)

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)