Talk:NVIDIA/nvidia-drivers

Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:

A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 10:39, 5 November 2024 (UTC)
:: Your reply ~~~~

>nvidia-drivers-340 + framebuffer

Talk status

This discussion needs help as of 2024-05-27.
Tip: To get this fixed sooner, use {{Proposal}}.

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"
GRUB_GFXMODE=1280x1024

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 https://forums.gentoo.org/viewtopic-p-8815902.html#8815902

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)

Handbook_Talk:Parts/Installation/Kernel#Add_Framebuffer_section is also relevant here.

— Waldo Lemmer 03:43, 27 May 2024 (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 ;							\
/bin/false)

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 (talk • contribs) 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)

I did not understand the problem. Anyway, is this discussion relevant for this talk page? I want to clean it. -- Jorge (talk) 23:05, 26 May 2024 (UTC)

The problem has been fixed (#ERROR: Kernel configuration is invalid.). You can close the discussion, thanks :D

— Waldo Lemmer 03:17, 27 May 2024 (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 needs a response from its author as of 2024-05-27.

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)

Is this discussion still relevant for this talk page after 15 months? I want to clean it. -- Jorge (talk) 23:05, 26 May 2024 (UTC)

15 months is rather short, at least for this wiki ;). There are a lot of open discussions, so it usually takes a while before a discussion gets looked at. I'm currently the only one who goes through that list. I've been able to reduce it from ~450 to 372, but if I keep being the only one who goes through it, I will probably get burnt out soon.

Generally, I try to categorize discussions instead of closing them. I know the help pages encourage us to close old discussions, but that was before I implemented the discussion categories, which will help to get stale discussions out of the way so we can focus on new discussions as well as discussions with proposals that are ready to be implemented into the Handbook.

— Waldo Lemmer 03:38, 27 May 2024 (UTC)

I don't recall suid ever being required when using x11-drivers/nvidia-drivers. Since you haven't been able to find the root cause, I'm guessing there was some other problem with your install that caused caused Xorg.wrap to not work with elogind.

Since no one has chimed in with their experience, I'm putting this discussion on hold until you're able to find the root cause.

— Waldo Lemmer 03:38, 27 May 2024 (UTC)

Are the open kernel drivers still very experimental?

Talk status

This discussion is done as of 2024-05-27.

The open source kernel modules are under Expert configuration with the following scary warning:

This is extremely experimental! Features are still missing and nvidia themselves don't claim that this is ready yet for desktop usage. Do not report bugs on Gentoo's Bugzilla unless it is packaging related.

However, the readme for x11-drivers/nvidia-drivers-550.78 (current amd64 stable) say:

Use of the open kernel modules on GeForce and Workstation GPUs should be considered Beta quality in this release and no longer requires setting of the "NVreg_OpenRmEnableUnsupportedGpus" nvidia.ko kernel module parameter. The open kernel modules are suitable for broad usage, and NVIDIA requests feedback on any issues encountered that are specific to them.

Should not this wiki be updated? -- Jorge (talk) 23:11, 26 May 2024 (UTC)

Ionen Wolkens (Ionen) and David Seifert (Soap) , could you take a look at this? I don't think many people know the answer to this question except the maintainers themselves :)

— Waldo Lemmer 02:53, 27 May 2024 (UTC)

It may still have some quirks, but yes it's not really experimental anymore and does not require a scary warning beside needing to know that it's only usable with Turing/Ampere+ GPUs, aka GTX 1650+ (the ebuild and USE description already warn about this -- on that note, recently dropped the "experimental" bit from the USE description too). Upstream's .run for upcoming 560.x drivers will even use it by default if all cards on the system support it, so there's little reason to discourage it anymore. Formerly it was lacking important features and discouraged by nvidia themselves, so "extremely" experimental was fitting. -- Ionen (talk) 03:27, 27 May 2024 (UTC)

Thanks for the fast response :D. Closing.

— Waldo Lemmer 04:53, 27 May 2024 (UTC)