From Gentoo Wiki
Jump to:navigation Jump to:search
This is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (~~~~), and indent successive comments with colons (:). Add new sections at the bottom of the page, under a heading (== ==). Please remember to mark sections as "open for discussion" using {{talk|open}}, so they will show up in the list of open discussions.

Missleading code-names

Talk status
This discussion is still ongoing.

Codename for 870M (GK104) is missing in mentioned article i found it on 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

Talk status
This discussion is done.

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 (talkcontribs) 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

Talk status
This discussion is done.

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 (talkcontribs) 27 December 2013

This material predates the Wiki. It was originally written in GuideXML for 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)


Talk status
This discussion is done.

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 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)


Talk status
This discussion is still ongoing.

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):

  • find out which card you are using.
    user $lspci | grep VGA
    01:00.0 VGA compatible controller: NVIDIA Corporation GT200 [*GeForce GTX 260*] (rev a1)
  • check 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.
    FILE /etc/portage/package.mask
  • check inside the ebuild which kernels are supported
    user $grep '<sys-kernel/gentoo-sources' /usr/portage/x11-drivers/nvidia-drivers/nvidia-drivers-340.107.ebuild
    ewarn "<sys-kernel/gentoo-sources-4.18"
  • check current kernel
    user $eselect kernel show
    Current kernel symlink:
  • 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
    root #emerge --ask =gentoo-sources-4.14.65
    do eselect etc and follow the upgrade guild (Kernel/Upgrade)
  • Upgrade the nvidia-drivers
    root #emerge @module-rebuild


— The preceding unsigned comment was added by Bw (talkcontribs) 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

Talk status
This discussion is done.

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 Brian Evans (Grknight) response.--BT (talk) 10:20, 22 April 2019 (UTC)

>nvidia-drivers-340 + framebuffer

Talk status
This discussion is still ongoing.

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

FILE /etc/portage/package.use/nvidia
x11-drivers/nvidia-drivers kms

2. Configuring the kernel

KERNEL Enable VESA VGA framebuffer
Bus options (PCI etc.)  --->
   [*] Mark VGA/VBE/EFI FB as generic system framebuffer
Device Drivers --->
   Graphics support --->
        Frame buffer Devices --->
            [*] VESA VGA graphics support
            [ ] Simple framebuffer support

3. Grub2 setup

FILE /etc/default/grubConfiguring framebuffer
GRUB_CMDLINE_LINUX_DEFAULT="video=vesafb vga=795 nomodeset console=tty1"

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

Available videomodes

root #hwinfo --framebuffer

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

I second this. after

Using CONFIG_SYSFB_SIMPLEFB=y is to me a suboptimal solution.

  1. Élément de la liste numérotée
  2. you will lose tty ([Ctr][F1],[Ctr][F2],[Ctr][F3]...)
  3. you will lose ability to see kernel message at boot

On the wiki having CONFIG_SYSFB_SIMPLEFB=y "seems" to be the default/best solution ,I doubt it for nvidia blob.

       Frame buffer Devices --->
          [ ] Simple framebuffer support
           Support for frame buffer device drivers --->
               [*] VESA VGA graphics support
               [*] EFI-based Framebuffer Support 

VESA VGA and EFI-based can be both selected and so should cover almost all cases
Grub2 setup from [User:Oschtan|Oschtan] is a nice touch but I belive by default without this grub config it should work fine for most cases ( usfull for hdpi)

--Jms (talk) 21:41, 12 February 2024 (UTC)

eselect opengl no longer needed

Talk status
This discussion is still ongoing.

I found out on #gentoo that eselect opengl set nvidia is no longer needed, having been replaced by libglvnd.

Users following the current instructions may try to install app-eselect/eselect-opengl when they realize that eselect opengl does not work, triggering blockers and lots of pain (

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

Talk status
This discussion is still ongoing.

(Don't know if it is important, but my Gentoo installation is on this laptop: - with GTX 950M / Optimus).

The Configuration/Drivers section of the wiki page said to run modprobe nvidia 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, xrandr only shows the integrated card (modesetting) as provider. I checked lsmod and only module nvidia is shown. Even the NVIDIA/Optimus page only mentioned to enable the nvidia kernel module.

I read the NVIDIA driver's documentation:

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

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 nvidia-drm instead of nvidia?

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

Failed to initialize DMA on Ryzen (AMD Secure Memory Encryption)

Talk status
This discussion is still ongoing.

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)ː
Related forum threadː

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

Note that "error" is actually the code

Talk status
This discussion is still ongoing.

If emerge --ask x11-drivers/nvidia-drivers 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 ;							\

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

— The preceding unsigned comment was added by Cm (talkcontribs) 2022-04-02

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

Talk status
This discussion is still ongoing.

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.

(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

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)

Correction: it's not needed to run Xorg as suid root, but rather only /usr/bin/nvidia-modprobe needs to be suid root instead! This is from package x11-drivers/nvidia-drivers, and thus if you're using FEATURES=suidctl, make sure /usr/bin/nvidia-modprobe is on a line of its own in file /etc/portage/suidctl.conf before emerging package x11-drivers/nvidia-drivers. In my above tests, /usr/bin/nvidia-modprobe wasn't suid but Xorg was. In my current test, Xorg isn't suid but nvidia-modprobe is, and I've rebooted once, can confirm that nvidia driver did load in Xorg.0.log of $HOME! -rws--x--- 1 root video 47760 09.02.2023 18:05 /usr/bin/nvidia-modprobe* --Correabuscar (talk) 08:11, 10 February 2023 (UTC)