Talk:NVIDIA/nvidia-drivers

Missleading code-names
Codename for 870M (GK104) is missing in mentioned article i found it on https://en.wikipedia.org/wiki/GeForce_800M_series. Someone should make a list of codenames to prevent possible isssues for the end-user.

-- Kreyren (talk) 14:35, 26 October 2018 (UTC)


 * Why? The nvidia-drivers package has no real use for codenames. --Grknight (talk) 19:21, 26 October 2018 (UTC)

Translation help
Hi, At the time of translating this page I met a problem with T:45 and T:60. Because of the breaking of a PRE block in two parts, the translation tool complains that the number of parentheses is not even and refuses to record the translation. I found a work around in merging the two parts in the first one, then using a dash in the second. Can this type of fragmentation be avoided or did I make any mistake ? — The preceding unsigned comment was added by Jaaf (talk • contribs) 18 July 2013

I don't know why titles and bodies are not separated from translation tool in this article -- Darkcircle(talk)


 * This is corrected now. If you notice this, we need to update the source article and add in either some whitespaces or comments to "link" the two parts together. --SwifT (talk) 18:26, 30 December 2016 (UTC)

Acknowledgements necessary
is the acknowledgements chapter realy necessary, I mean its a wiki who editied is freely available in the history. Besides it does not realy contribute to the topic. You don't see this anywhere else on the gentoo wiki. If it where up to me it would be deleted, or is there some hidden reason I'm missing? — The preceding unsigned comment was added by Superpwnzormegaman (talk • contribs) 27 December 2013

This material predates the Wiki. It was originally written in GuideXML for gentoo.org. The Acknowledgements keeps traceability back to the original authors of the document on the webeite. The Wiki history only has changes since the page was moved to the Wiki.

The original Wiki page will be credited to whoever did the GuideXML to Wiki conversion, which in most cases, will not be the original author(s) credited in the GuideXML. NeddySeagoon (talk) 10:42, 23 August 2015 (UTC)

Contradiction
This paragraph

The x11-drivers/nvidia-drivers package contains the latest drivers from nVidia with support for all cards, with several versions available depending on how old the card is. It uses an eclass to detect what kind of card the system is running so that it installs the proper version.

Seems to contradict

If the card has been identified as a legacy card then mask the more recent releases of nvidia-drivers, i.e https://forums.gentoo.org/viewtopic-t-1027244.html shows that nvidia-drivers does not just work for legacy cards.

NeddySeagoon (talk) 10:42, 23 August 2015 (UTC)


 * Ditto. nvidia-drivers-96xx branch will not install on older hardware due to the nvidia-drivers-96xx relying on older xorg-server versions which are now masked. And the nvidia-drivers-96xx hardware sometimes either works poorly with the nouveau drivers, or even sometimes Nouveau is unreliable or has critical bugs, especially when using other than one standard monitor scenarios.  Most features such as TV OUT are not functioning when using Nouveau, to include unreliable issues when using more than one monitor. (ie. VGA + VGA, etc.)  I have not, however, checked back to see if my NVIDIA 96xx hardware is any more stable when using Nouveau recently.  I would have assumed, especially by now(!), NVIDIA would have pushed their code for this old 96xx hardware into Nouveau! Shrugs. --Roger (talk) 13:47, 23 August 2015 (UTC)


 * Updated article to say "most cards". In the future, feel free to update the article accordingly, we appreciate all the help we can get in keeping the articles correct. --SwifT (talk) 18:30, 30 December 2016 (UTC)

If you use compat in use flags and then startx you will get segmentation fault. The only fix is to not use compat in use tags. Tmcca (talk) 17:07, 27 May 2019 (UTC)

Upgrade
It is always a hassle to upgrade the nvidia-drivers as it is bound to specific kernel versions, but this data is not easily available. The following steps guild you quicker through the forest. Steps to take in order to upgrade the nvidia-drivers (Oct 2018): done.
 * find out which card you are using.
 * check https://www.nvidia.com/Download/Find.aspx for latest driver for your graphics card (see 1). e.g.: 342.01
 * check if ebuild for above version exist, if not go to the latest below that version. 342.01 does not have an ebuild, 340.107 is the latest)
 * update /etc/portage/package.mask to allow nvidia-drivers to upgrade. e.g. mask any package above the to be installed version.
 * check inside the ebuild which kernels are supported
 * check current kernel
 * Is current_kernel 4.4.84 < 4.18? OK, good to go. (you can upgrade to a linux kernel lower than 4.18) in this case, 4.14.65 is the latest stable kernel  do eselect etc and follow the upgrade guild (Kernel/Upgrade)
 * Upgrade the nvidia-drivers

— The preceding unsigned comment was added by Bw (talk • contribs) on 8 July 2018, updated by the same user on 14 October 2018, and finally wikified by Grknight on 15 December 2018

Article was moved without translation
Pages which is under translations should be moved with translated subpages. --Cronolio (talk) 09:28, 22 April 2019 (UTC)


 * I mistakenly moved the page without translations. There is an open discussion about it in Talk:NVIDIA but I'm still waiting for response.--BT (talk) 10:20, 22 April 2019 (UTC)

>nvidia-drivers-340 + framebuffer
Many people do not understand how to make the framebuffer work. It is often suggested for new nvidia video drivers to use Simple Framebuffer. Often this does not produce the desired effect. To solve this problem, the following solution is proposed.

1. Required condition

2. Configuring the kernel

3. Grub2 setup

vga=795 similarly vga=0x031b => 1280x1024, 24 bit

Available videomodes

Oschtan (talk) 06:35, 16 January 2020 (UTC)

no longer needed
I found out on #gentoo that is no longer needed, having been replaced by.

Users following the current instructions may try to install when they realize that  does not work, triggering blockers and lots of pain (https://forums.gentoo.org/viewtopic-p-8431666.html)

This comment also applies to Xorg/Guide, and i am repeating it there as well. --Orionbelt (talk) 05:11, 17 March 2020 (UTC)


 * Feel free to update this in a way that covers the change accounting for if users disable the USE flag --Grknight (talk) 12:48, 17 March 2020 (UTC)

(Need confirmation) Correct kernel module to enable
(Don't know if it is important, but my Gentoo installation is on this laptop: https://www.asus.com/Laptops/K501LX/specifications/ - with GTX 950M / Optimus).

The Configuration/Drivers section of the wiki page said to run to load the kernel module into memory. But when I only load the NVIDIA module like the wiki mentioned, starting X server on my Gentoo installation only result in black screen with no backlight, only shows the integrated card (modesetting) as provider. I checked and only module   is shown. Even the NVIDIA/Optimus page only mentioned to enable the  kernel module.

I read the NVIDIA driver's documentation:

https://download.nvidia.com/XFree86/Linux-x86_64/440.82/README/primerenderoffload.html

In the section it said to load module. So I ran. After that, I checked and it also load both   and   modules. Then X server started correctly without any problem ( shows both integrated card and NVIDIA as providers). NVIDIA Prime offload also works as expected (tested with /).

I can assure that I follow the NVIDIA and NVIDIA/Optimus guides on Gentoo wiki precisely, but the black screen problem with X only solved with the above solution.

Maybe the correct kernel module to load for the NVIDIA driver to work is  instead of  ?

Sweet potato (talk) 03:05, 27 April 2020 (UTC)

Failed to initialize DMA on Ryzen (AMD Secure Memory Encryption)
It appears this has been fixed by NVIDIA in recent versions. I'm currently running Gentoo Linux (amd64), Linux kernel 5.10.27, NVIDIA drivers 460.56 with AMD SME enabled (dmesgː '[   0.000000] AMD Memory Encryption Features active: SME') and graphics seems to be working fine.

Needs to be confirmed by other users.

Related bug (my own)ː https://developer.nvidia.com/nvidia_bug/2865023 Related forum threadː https://forums.developer.nvidia.com/t/unable-to-start-x-failed-to-initialize-dma/64925

Maxxim (talk) 22:08, 4 April 2021 (UTC)

Note that "error" is actually the code
If  is ran at some time there will be the following output: * Preparing nvidia module make -j8 HOSTCC=x86_64-pc-linux-gnu-gcc 'LDFLAGS=-m elf_x86_64' NV_VERBOSE=1 IGNORE_CC_MISMATCH=yes SYSSRC=/usr/src/linux SYSOUT=/usr/src/linux modules make[1]: Entering directory '/usr/src/linux-5.15.23-gentoo' test -e include/generated/autoconf.h -a -e include/config/auto.conf || (		\ echo >&2;							\ echo >&2 " ERROR: Kernel configuration is invalid.";		\ echo >&2 "         include/generated/autoconf.h or include/config/auto.conf are missing.";\ echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to fix it.";	\ echo >&2 ;							\ /bin/false)

which could be misleading that there is an error but actually it is just the code that checks for an error.


 * Thanks for the observation - this sort of output must have tripped some people up before. Not sure where the best place would be for this, maybe in this article's troubleshooting section as a short entry ? The issue may be more prevalent than for these drivers though - certainly for warnings spewed out, which are common, and could worry newcomers. I wonder if if might merit an entry in the FAQ...


 * Feel free to add it to the troubleshooting section if you think that is a good idea ;) - Contributor's guide.


 * -- Ris (talk) 19:19, 2 April 2022 (UTC)

If using FEATURES=suidctl then add /usr/libexec/Xorg.wrap to /etc/portage/suidctl.conf before emerging xorg-server with USE=suid
First of all, xorg-server package must be, apparently, emerged with USE=suid (USE=elogind is not good enough), so that /usr/libexec/Xorg.wrap is suid root, otherwise you will get something like the following in $HOME/.local/share/xorg/Xorg.0.log and thus nvidia driver won't be loaded:
 * [   78.272] xf86EnableIO: failed to enable I/O ports 0000-03ff (Operation not permitted)
 * [   78.275] (EE) NVIDIA: Failed to initialize the NVIDIA kernel module. Please see the
 * [   78.275] (EE) NVIDIA:     system's kernel log for additional error messages and
 * [   78.275] (EE) NVIDIA:     consult the NVIDIA README for details.
 * [   78.275] (EE) NVIDIA:     system's kernel log for additional error messages and
 * [   78.275] (EE) NVIDIA:     consult the NVIDIA README for details.

(the first line with I/O ports may well be unrelated!) and if it's suid root properly, then the log is now located at /var/log/Xorg.0.log, so don't make the mistake, like I did, of looking at the wrong log!

If it does work properly(ie. it's suid root), you'll see something like this:
 * [ 6330.428] (**) NVIDIA(G0): Depth 24, (--) framebuffer bpp 32
 * [ 6330.428] (==) NVIDIA(G0): RGB weight 888
 * [ 6330.428] (==) NVIDIA(G0): Default visual is TrueColor
 * [ 6330.428] (==) NVIDIA(G0): Using gamma correction (1.0, 1.0, 1.0)
 * [ 6330.428] (**) NVIDIA(G0): Enabling 2D acceleration
 * [ 6330.428] (**) NVIDIA(G0): Enabling 2D acceleration

and a lot more lines with nvidia in them, showing that nvidia driver has loaded successfully.

If using FEATURES=suidctl then add /usr/libexec/Xorg.wrap to /etc/portage/suidctl.conf before emerging xorg-server with USE=suid. Double check that /usr/libexec/Xorg.wrap is suid root (with ls -la /usr/libexec/Xorg.wrap:
 * -r-s--x--x 1 root root 14568 10.02.2023 07:53 /usr/libexec/Xorg.wrap*

Now, I don't know exactly why suid root is needed for X aka running Xorg as root (TODO: find the root cause) therefore the above might just be a solution for the symptom rather than one for the real cause why nvidia driver doesn't get loaded in non-suid Xorg. --Correabuscar (talk) 07:57, 10 February 2023 (UTC)