From ArchWiki
Latest comment: 27 May by Latenight.bread! in topic Should Explicit Sync be mentioned?


NVoption Online Version - great tool to make tv-out easy and fast

[I'm using gmplayer with gl and twinview] [1] —This unsigned comment is by Suw (talk) 01:23, 23 March 2006‎. Please sign your posts with ~~~~!

A user found this useful to get TV-Out working with an old Geforce 2 MX: nvtvAUR -- Alad (talk) 13:56, 3 March 2016 (UTC)Reply[reply]

'/dev/nvidia0' Input/Output error... suggested fixes

Can anyone verify that the BIOS related suggestions work and are not coincidentally set (either automatically when changing the IRQ or turning off ACPI) while troubleshooting? I have found little information that confirms any of the suggestions would work. The file permissions thing seems to be completely unfounded and never works (as noted in the article) that I could find. It would probably be a good idea if we cleaned out items that have not been verified to work. For my setup I was having this error and none of the items in the wiki nor the many file permission search results worked. -- click, them so hard 19:16, 4 March 2012 (EST)

I've added an Accuracy template, please next time add it yourself so that discussions like this are more visible. -- Kynikos 05:40, 6 March 2012 (EST)

Run a test

There is confusing paragraph saying You can run a test to see if the Xorg server will function correctly without a configuration file.. IMHO, it should be clarified what kind of test the author has in mind, an exact command would be helpful. Currently, this suggestion is simply confusing, especially to less experienced users. --Mloskot (talk) 19:52, 26 November 2012 (UTC)Reply[reply]

It's strange. I agree. The link goes to the section for running X. After a beat, I realized you simply try to launch X. And in my case the screen was black. So the "test" failed. A better instruction might say to try launching launching X, and then provide the link which describes all the ways this is done--depending on your configuration. Xtian (talk) 22:05, 21 October 2017 (UTC)Reply[reply]
Over 7 years after the original comment (with which I agree), I've amended the labelling of that link to remove the suggestion that the reader will find a test described there. --Ghepardo (talk) 17:44, 29 March 2020 (UTC)Reply[reply]


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)Reply[reply]

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)Reply[reply]

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)Reply[reply]

Accuracy of driver selection

A thread on the forums revealed that nvidia is more conservative in their suggestion than needed and checking their website tells you to use an older driver (nvidia-340xx) while the latest 'nvidia' one will do just fine. Gusar suggested the removal of the second point in the 'Installing' section. Do we want to get rid of this potentially useful, although somewhat confusing info? -- Karol (talk) 02:52, 15 November 2014 (UTC)Reply[reply]

Well, I've rewritten the second point to make it clearer, I hope I got it correctly. However steps 2 and 3 there should probably merged into one, because they deal with the same problem, i.e. finding the correct driver to install. Maybe we could use a table? (just brainstorming). -- Kynikos (talk) 03:47, 16 November 2014 (UTC)Reply[reply]


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"

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)Reply[reply]

xorg-server 1.20

Seems with xorg 1.20 some nvidia packages are not supported anymore e.g. nvidia-340xx - no matiching ABI. Should we insert a warning? Ua4000 (talk) 07:03, 20 May 2018 (UTC)Reply[reply]

PRIME Render Offload in closed-source drivers

Is offload is supported now in these drivers? DragonX256 (talk) 05:01, 30 August 2019 (UTC)Reply[reply]

Experimental Power Management features (for preserving video memory across suspension)


"Power Management" - misleading

How is this misleading? It is a descriptive term, the official term that NVIDIA uses, and also the term used by maintainers of the nvidia-utils package (see [2]). Sure, it's confusing that Power Management and Dynamic Power Management are quite different beasts, but it's even more confusing to censor the phrase "Power Management" altogether from the section. We should really mention "Power Management" or "Power Management Support" somewhere in that section.

In case it's not clear, power management refers to suspend-to-RAM and suspend-to-disk computer features, this isn't an NVIDIA specific thing, or anything new ... Neven (talk) 22:00, 8 September 2020 (UTC)Reply[reply]

The purpose of this wiki is to make things clearer, not to copy-paste from official manuals. If nvidia uses misleading wording, there is no reason to follow that. -- Lahwaacz (talk) 08:09, 9 September 2020 (UTC)Reply[reply]
Again, how is it misleading? As I clearly said in my above comment, which it appears you couldn't bother reading in its entirety, the fact that power management includes system sleep is long established semantics, common throughout the computing world (not NVIDIA specific). Neven (talk) 10:21, 9 September 2020 (UTC)Reply[reply]
I agree that the fact that "power management" includes system sleep is long established semantics when you talk about system power management, but I disagree that "power management" is the best term to describe what is going on here. The nvidia driver connects to the suspend pipeline to save the GPU state, including (part of) the video memory. The purpose of the "new" method is to save full video memory, which is purely a visual convenience thing, and some "advanced" CUDA state. There is nothing related to saving or otherwise managing power of the GPU, which is why I find the term "power management" inappropriate for this section. The section should use terms which clearly describe what is going on. -- Lahwaacz (talk) 14:42, 9 September 2020 (UTC)Reply[reply]

Common configuration

Well, it's new, of course not everybody is using it; but, at least on my system, chromium (and other heavy GPU users, too, I assume) is currently unusable (more correctly - unviewable) after resuming from system sleep without this feature. Surely this is will become a very common configuration for NVIDIA users soon, at least those that also need to suspend their system. Neven (talk) 22:00, 8 September 2020 (UTC)Reply[reply]

It might be new because nvidia added it in a recent driver version, not because few people use it. The fact that your system needs it does not make it common. -- Lahwaacz (talk) 08:09, 9 September 2020 (UTC)Reply[reply]


I'm not sure what are you asking exactly, it seems like it's a question directed more at NVIDIA than at me; but I can say that it seems like it's not perfect yet, as I had some worrying messages in dmesg after resuming with the new features enabled and Chromium running. Everything seemed to be OK apart from the messages, though, so clearly a great improvement. Neven (talk) 22:00, 8 September 2020 (UTC)Reply[reply]

Upstream documentation

Linked in the second sentence of the section, also available in nvidia-utils package (powermanagement.html). Titled "Chapter 21. Configuring Power Management Support". Neven (talk) 22:00, 8 September 2020 (UTC)Reply[reply]

GPU at 0000:0X:00.0 has fallen off the bus.

Whilst using the nvidia driver with linux and linux-ck my machine randomly freezes with only this in journal, currently using Geforce GTS 450 with the 390xx driver, similar thread on BBS

style="background: inherit; color: inherit; vertical-align: middle; text-align: center; "|

                              Nov 24 15:55:56 archlinux kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module  390.138  Thu May 14 01:01:53 PDT 2020 (using threaded interrupts)
                               Nov 24 16:04:49 hawker64 kernel: NVRM: GPU at PCI:0000:02:00: GPU-feeae056-097a-fe32-3f56-3732296882d2
                               Nov 24 16:04:49 hawker64 kernel: NVRM: Xid (PCI:0000:02:00): 79, GPU has fallen off the bus.
                                Nov 24 16:04:49 hawker64 kernel: NVRM: GPU at 0000:02:00.0 has fallen off the bus.
                                Nov 24 16:04:49 hawker64 kernel: NVRM: A GPU crash dump has been created. If possible, please run
                                NVRM: as root to collect this data before
                                NVRM: the NVIDIA kernel module is unloaded.	

A search on BBSshows that its a known common issue and apparently the error message is somewhat generic and could be down to faulty hardware or a regression in driver or other software, reseating card in PCI slot is advised, i have removed the nvidia-drm.modeset=1 parameter and all is well for now. putting the graphics card into persistent mode: sudo nvidia-smi -pm 1 apparently works for some.
[edit] Further testing results in same errors even without the nvidia-drm.modeset=1 parameter, perusing nvidia forums suggests parameter pcie_aspm=off works for some users, so im now trying this.
[update] pcie_aspm=off did not rectify maters, however since updating to kernel 5.9.12-2-ck-nehalem yesterday i've been freeze free. It would appear im not alone,according to this reddit thread

—This unsigned comment is by Cirrus (talk) 16:17, 25 November 2020‎. Please sign your posts with ~~~~!

Merge "custom kernel" section into main installation section

The reasons include: 1. The custom kernel setup also needs most of the instructions to determine the card and appropriate drivers 2. Drivers for older cards are dkms versions anyway.

G3ro (talk) 20:38, 3 November 2021 (UTC)Reply[reply]

Add a table for drivers instead?


Release Series Installation Cards Links Notes
Current Maxwell (NV110) series and newer
Kernel Package
linux nvidia
linux-lts nvidia-lts
custom or multiple kernels nvidia-dkms
Special Type Package
Beta nvidia-betaAUR
GeForce 930~, 10-30, and Quadro/Tesla/Tegra cards and newer (for a detailed list, see Official Readme) Official Readme blabla
Legacy Kepler (NVEx) series
Kernel Package
All nvidia-470xx-dkmsAUR
GeForce 630-920 - blabla
Legacy Fermi (NVCx + NVDx) series
Kernel Package
All nvidia-390xx-dkmsAUR
GeForce 400/500/600 - blabla
Legacy For even older cards (released in 2010 or earlier), have a look at #Unsupported drivers. - - - blabla

What do you think?

G3ro (talk) 21:39, 9 November 2021 (UTC)Reply[reply]

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. 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 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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

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)Reply[reply]

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)Reply[reply]

Framebuffer consoles experimental support

From 545.29 release [3]:

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)Reply[reply]

`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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

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 [4] , 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)Reply[reply]