»NVIDIA, Debian, and Xorg

I have been using the Debian distribution of Linux since about 1998, after having gone through Slackware and Red Hat during college. I like Debian, but moreover, I am used to it. So, while I would love to experiment with a newer distro like Arch, in my precious free time that isn't at the top of my list.

The biggest drawback of using Debian for anything cutting-edge is that it moves very slowly: even the unstable distribution is often well behind my needs. I run into this with the NVIDIA drivers more often than anything else. Since I prefer gaming in Linux (even with hibernate, dual booting is kind of a pain), I occasionally run into a situation in which the stable/testing NVIDIA drivers are not new enough to play something. I have been searching for a solution to this problem for years that doesn't involve me trying to build my own driver packages from an NVIDIA .run driver package, and it looks like NVIDIA has themselves done it: the official CUDA repo can be used to get access to the latest released NVIDIA graphics drivers in .deb form in a way that appears clean and compatible with Debian 13 (Trixie). It worked almost out-of-the-box according to those instructions, but I had to take a few additional steps:

Set an apt pin for packages from the NVIDIA origin. You can do this with this simple addition to your apt preferences:
```
 Package: *:any
 Pin: release o=NVIDIA
 Pin-Priority: 995
```
NB: This is potentially a security risk because it will override any package that exists in that repo. You could limit it to particular package name patterns if you are concerned about this possibility. I personally use:
```
 Package: /nvid|^libnv|^libxnv|cuda|dkms/:any
```
apt install --reinstall xserver-xorg-video-nvidia because some out-of-order purge occurred that removed the symlink from /usr/lib/xorg/modules/extensions/libglxserver_nvidia.so to libglxserver_nvidia.so.<VERSION> in the same directory, which broke GLX (OpenGL). (NB: This is a bug, but I haven't tracked down the cause.) It took me a day to run into this problem because I don't use a lot of OpenGL applications, but I found it strange that Borderlands 4 ran (albeit with severe visual artifacts) while the ancient City of Heroes brought up a black screen. I discovered the cause of the problem by first checking inxi -Gxz, which showed me that the wrong stack was in use for OpenGL, even though EGL and Vulkan were both handled properly; and then by noticing a line in my Xorg.0.log:
```
 NVIDIA: Failed to load module "glxserver_nvidia" (module does not exist, 0)
```
A quick locate glxserver_nvidia later, along with a comparison to a machine still using the Debian-packaged stack and a quick dpkg -S of the library itself, led to the obvious workaround.

I had to recreate the various module blacklists and options that were provided by the Debian-packaged driver. I created a file /etc/modprobe.d/nvidia-krose.conf containing:

 # You need to run "update-initramfs -u" after editing this file.

 # Nouveau must be blacklisted here as well beside from the initrd to avoid a
 # delayed loading (for example on Optimus laptops where the Nvidia card is not
 # driving the main display).

 blacklist nouveau
 blacklist amdgpu

 # Enable complete power management. From:
 # file:///usr/share/doc/nvidia-driver/html/powermanagement.html

 options nvidia NVreg_TemporaryFilePath=/var/tmp
 options nvidia NVreg_EnableS0ixPowerManagement=1
 options nvidia NVreg_PreserveVideoMemoryAllocations=1

followed by update-initramfs -k all -u.

Finally, I had to reenable the nvidia-suspend support that was moved from a separate nvidia-suspend package into the driver itself:
```
 sudo systemctl enable nvidia-suspend.service nvidia-resume.service nvidia-hibernate.service
```
Note that you might need to disable them first and then re-enable them, if removing the nvidia-suspend package left systemd's config in a bad state.