This subject has been around for a while but I think it needs an update. I have experienced the issue several times before and I have always been able to fix it by reinstalling the driver. However with a recent system update, no such luck.

My system is Ubuntu 22.04 with Kernel: 6.8.0-124-generic x86_64 bits, and a dual head graphics card NVIDIA GeForce GT 710. The correct driver is nvidia-driver-470.

The update installed the nvidia driver 535 which doesn't work. Attempts to install the 470 driver using apt install ignores the 470 driver and installs the 535 instead. I understand that this is because the 470 driver is no longer supported even though it is a common piece of hardware and is still available.

I was fortunate to discover after much gnashing of teeth that I could force the system to use a generic driver (Nouveau) by:

sudo apt purge "*nvidia*"

sudo apt autoremove --purge

sudo reboot

Then by going to Additional Drivers I found I could now select nvidia-driver-470 and install. Now things work again!

So my question is what exactly is going on? Also is it going to be safe to install future updates without breaking my system?

OK. Spent nearly day on this and nearly chucked the card out!! But, got it going and in near-smug-mode, so posting here incase it helps...

• Kubuntu 24.04 LTS ("noble"), kernel 7.0.0-28-generic (HWE kernel, much newer than the 24.04 GA kernel)
• List item KDE Plasma 5.27, Wayland session (KWin)
• Intel CometLake-S UHD Graphics 630 (motherboard iGPU) driving 2 monitors
• NVIDIA GeForce GT 710 (GK208B, "Kepler" generation, PCI ID 10de:128b) driving a 3rd monitor
• This is a hybrid multi-GPU desktop: two different graphics drivers are both live at once (i915 for Intel, nouveau/nvidia for the GT710).

There were two completely separate problems, hit one after the other!! Both had to be fixed before the card worked properly.

PROBLEM 1: No signal at all from the GT710 (driver conflict)

Symptom

Motherboard/Intel outputs worked fine. The GT710 gave nothing. nvidia-smi reported "couldn't communicate with the NVIDIA driver".

Root cause

The system had BOTH nvidia-driver-470 and nvidia-driver-535 installed at once!?

The kernel log made this explicit:

NVRM: The NVIDIA GeForce GT 710 GPU installed in this system is NVRM: supported through the NVIDIA 470.xx Legacy drivers. NVRM: The 535.309.01 NVIDIA driver will ignore NVRM: No NVIDIA GPU found.

An extra trap (i think Ubuntu 24.04 specific) was that the newest archive revision of nvidia-driver-470 (470.256.02-...5, from noble-updates) has been turned into a transitional dummy package that just depends on nvidia-driver-535 — My guess is it's Ubuntu's way of nudging people off the legacy branch (Thanks guys! lol). So installing "nvidia-driver-470" normally silently pulls 535 back in and recreates the exact same conflict.

Once the correct 470 revision's DKMS module was building, it failed with missing headers (os-interface.h, nvmisc.h, etc.). The driver's Kbuild file adds it's include path via aEXTRA_CFLAGS variable which doesnt seem to work!?! It is fixable with a one-line patch to the vendored Kbuild file (ccflags-y += $(EXTRA_CFLAGS)).

After fixing the include path, the build then failed on real kernel API breakage - f_dentry missing in struct file, proc_ops, phys_to_dma, del_timer_sync, acpi_bus_get_device, dma_is_direct, drm_gem_object_put_unlocked all missing or no right.

My guess is that the 470.xx driver source is early 2020's and has no compatibility shims for a kernel this new. So gave up.

So NVIDIA route is a dead end for GT710. But.... nouveau driver looked promising...

Actual Fix

Remove every trace of the NVIDIA driver:-

sudo apt purge -y '^nvidia-.*' '^libnvidia-.*' '^xserver-xorg-video-nvidia.*'
sudo apt autoremove -y

Install nouveau's Xorg driver:-

sudo apt install -y xserver-xorg-video-nouveau

Stop the old legacy nvidiafb framebuffer driver from grabbing the card before nouveau's proper KMS driver does:-

echo "blacklist nvidiafb" | sudo tee /etc/modprobe.d/blacklist-nvidiafb.conf
sudo update-initramfs -u

And do a reboot to get it all going;

sudo reboot

After reboot, check that nouveau now owns the card:

lspci -k | grep -A3 "NVIDIA"

That should show: Kernel driver in use: nouveau

At this point the card finally produced a picture — but it was corrupted. That was problem 2 :-)

PROBLEM 2: GT710 output is garbled (multi-GPU Wayland compositing bug)

Symptom

• My two Intel-driven monitors were perfectly fine.
• The GT710-driven monitor showed a corrupted image - just looked weird, 5 columns of odd lines
• But, and this confused me for a bit, mouse cursor on that same monitor rendered perfectly cleanly on top of the garbled desktop! I'm told it is because the mouse cursor gets rendered differently...

However, that mouse detail was the key! The mouse cursor is drawn by a dedicated DRM overlay plane that the GPU scans out directly - no compositor rendering involved. It meant that the electronics outputing to the screen was ok, it was just s/w!

Root cause

So, it is a mixed GPU desktop. Some screens using the Intel GPU and some using the GT710 NVidia. So, KWin's Wayland/DRM backend does all OpenGL scene compositing on whichever GPU is flagged "boot_vga" (Can be checked with cat /sys/bus/pci/devices/*/boot_vga) - in this case, the Intel GPU.

For any output from a different GPU (in this case the GT710), KWin has to copy/export the finished composited frame across to that GPU for scanout.

That cross-GPU doesnt work with Intel/nouveau. No idea why, I gave up...

What did NOT fix it (tested via KWin env vars, for the record): KWIN_DRM_USE_MODIFIERS=0 — no change KWIN_DRM_NO_AMS=1 — no change KWIN_DRM_NO_DIRECT_SCANOUT=1 — no change KWIN_COMPOSE=Q (full software/CPU compositing) — FIXED the corruption but performance was unusable (cursor updating roughly twice a second across all three monitors), even after disabling blur/ contrast/animation effects to reduce CPU load.

Actual fix

Force GT710 (via nouveau) to be the PRIMARY render GPU instead of Intel, so the GT710 renders its own output with no cross-GPU copy. The Intel-attached monitors then get the copy done by the nouveau-rendered buffer), which is the Optimus-style direction and works cleanly. Full GPU acceleration on all three monitors, no corruption, normal responsiveness!!!

Steps:

1. Find the /dev/dri/cardN device for each GPU:

for f in /sys/bus/pci/devices/*/boot_vga; do echo "$f: $(cat $f)"; done
ls -la /dev/dri/by-path/

Match the PCI address of the NVIDIA/nouveau card (boot_vga = 0) to its /dev/dri/cardN symlink under by-path.

2. Create a KDE session environment script KDE Plasma sources every *.sh file in ~/.config/plasma-workspace/env/ before starting the session:

mkdir -p ~/.config/plasma-workspace/env
cat > ~/.config/plasma-workspace/env/kwin-drm-fix.sh << 'EOF'
#!/bin/sh
export KWIN_DRM_DEVICES="/dev/dri/<cardX>:/dev/dri/<cardY>"
EOF
chmod +x ~/.config/plasma-workspace/env/kwin-drm-fix.sh

Replace with the NVIDIA/nouveau device (list it FIRST — this makes it primary) and with the Intel device. Colon-separated for more than one GPU.

3. Reboot or Log out and back in A full reboot isn't needed for this step, only the initial driver-binding steps in Problem 1 needed a reboot).

Hope that helps... But ucky but saves a few $$ on a new Card no no real reason! :-)