Package Details: nvidia-340xx 340.108-37

Git Clone URL: https://aur.archlinux.org/nvidia-340xx.git (read-only, click to copy)
Package Base: nvidia-340xx
Description: NVIDIA drivers for linux, 340xx legacy branch
Upstream URL: https://www.nvidia.com/
Licenses: custom
Conflicts: nvidia
Submitter: simonsmh
Maintainer: JerryXiao
Last Packager: JerryXiao
Votes: 72
Popularity: 0.73
First Submitted: 2019-06-07 10:29 (UTC)
Last Updated: 2024-05-10 16:52 (UTC)

Pinned Comments

JerryXiao commented on 2022-10-13 03:51 (UTC) (edited on 2022-10-14 02:44 (UTC) by JerryXiao)

For testing users, contributors: check out https://github.com/archlinux-jerry/nvidia-340xx
Warning: force push may happen to match the aur tree

Latest Comments

« First ‹ Previous 1 .. 22 23 24 25 26 27 28 29 30 31 32 .. 58 Next › Last »

graysky commented on 2021-05-10 15:03 (UTC)

OK, I honestly forgot that I included an example config file. Since I don't have the hardware for testing, and since I still don't have a sense from users that it is a requirement, I will leave it in the post_install and depend on the user's ability to read pacman's output and manually copy the example over.

auriculaire commented on 2021-05-10 14:22 (UTC)

@graysky I noted the advice that was given after installing the module on kernel 5.11: "-> You must tell Xorg to use the nvidia driver with kernels >=5.11.0. -> Minimal xorg config example: /usr/share/nvidia-340xx/20-nvidia.conf -> To place in /etc/X11/xorg.conf.d/ " In fact, as @jayache80 pointed out, it is in /etc/X11/xorg.conf (and not in xorg.conf.d/) that the "Files" section must be filled in. However, I am not able to conclude whether 20-nvidia.conf is mandatory or not. I don't remember to create it myself... Thanks to you. Sincerely.

Translated with www.DeepL.com/Translator (free version)

lucasrizzini commented on 2021-05-10 14:11 (UTC)

Not specifically.

graysky commented on 2021-05-10 13:45 (UTC)

I have not been following this closely. Is 20-nvidia.conf a requirement for all setups of this driver with 5.12? Should the package provide an equivalent?

auriculaire commented on 2021-05-10 13:07 (UTC)

@jayache80 Thank you so much! ...I just added to my xorg.conf the two lines you mention, and archlinux with the latest kernel (uname -mr = 5.12.2-arch1 x86_64) boots well on lightdm and gdm for xfce, gnome and kde. Only sddm doesn't want to show up... Sincerely

jayache80 commented on 2021-05-09 10:09 (UTC) (edited on 2021-05-09 23:36 (UTC) by jayache80)

I'm an idiot. The order of ModulePath entries was somehow incorrect in my xorg.conf:

As in the provided 20-nvidia.conf, and is nicely called out to the user upon installing this driver, it absolutely needs to be:

Section "Files"
  ModulePath   "/usr/lib64/nvidia/xorg"
  ModulePath   "/usr/lib64/xorg/modules"
EndSection

However, somehow I had it reversed. The following is WRONG:

Section "Files"
  ModulePath   "/usr/lib64/xorg/modules"
  ModulePath   "/usr/lib64/nvidia/xorg"
EndSection

Sorry for all the noise.

The following can be ignored as it was totally a red herring. DRM is just different now and you can expect that it will be initialized differently and you won't see the same system log output in 5.11+ as 5.10.

I think I know why I'm having problems on 5.11/5.12 but not 5.10. I noticed in the system log on 5.10 that DRM is getting initialized properly:

[drm] Initialized nvidia-drm 0.0.0 20150116 for 0000:02:00.0 on minor 0

However, no such output in 5.11/5.12 when using this kernel module. That stuff is taken care of in nv-drm.c starting essentially with the call to nv_drm_pci_init from nv_drm_init but only #if defined(NV_DRM_AVAILABLE). I proved it wasn't being called with some printk's.

Something seems a little strange with the build system as that is defined in 5.10 but is not defined when building 5.11/5.12. I even added

#define NV_DRM_AVAILABLE

to the top of nv-drm.c to no avail. It's probably something really simple and I'll bet this will fix my issues (but I don't know about anyone else's).

Anyone know what's up with that define?

MegaDeKay commented on 2021-05-08 15:03 (UTC)

Back in March on 5.11, people were having luck with GTK based greeters but Qt based ones weren't working (e.g. SDDM). So Googling around the error that @jayache80 reported, I found some references to people having weird problems with Qt that were fixed with setting QT_X11_NO_MITSHM=1 in someplace like /etc/environment. Maybe this explains why some people have luck and some don't? I'll admit that this is far-fetched, but it might be worth a shot given that it is low effort to try. The rabbit hole I went down are in the links below. Disabling the nvidia splash screen with Option "NoLogo" "1" in xorg.conf might not help, but it wouldn't hurt either.

https://forum.mxlinux.org/viewtopic.php?t=53653

https://forum.mxlinux.org/viewtopic.php?f=108&t=53603&start=10

https://ubuntuforums.org/showthread.php?t=2423870

auriculaire commented on 2021-05-08 13:46 (UTC)

I think that linux arch users who use this module have been running on linux-lts since the arrival of the latest 5.11.x and 5.12.x kernels with which for me this module has never been operational ..... I read the comments every day while waiting for the miracle solution. Have a good day and good luck everyone.

tioguda commented on 2021-05-08 11:55 (UTC)

This is the change I make to compile for Manjaro, I believe that there is no significant change that I have not reported here before.

graysky commented on 2021-05-08 10:56 (UTC)

I'm not sure what I can do with your reply. You're modifying the PKGBUILD I provide to build without dkms on a foreign distro and you're reporting that it works. You're not sharing the code you're using to do this so it's impossible to make a comparison back to help users of Arch build via dkms.

What if you uninstall your non-dkms tweaked package and try building with this unmodified. Does that build? If so do it give a functional module?