URGENT - NVIDIA - REL15.0: 580.119.02_1 of nvidia driver/drm61/kmod - ARE KNOWN BROKEN

CShell

CShell

I have been experiencing this exact problem for a few days... but I assumed "it was me" :cool: -- but it turns out --- IT IS NOT ME !

=> This is a PRETTY AWFUL EXPERIENCE -- CAN WE GO BACKWARDS OR FORWARDS on the NVIDIA packages? Thank you !

[14.3-RELEASE-p7]

Code: 
$ pkg info | grep nvidia
linux-nvidia-libs-580.119.02   NVidia graphics libraries and programs (Linux version)
nvidia-driver-580.119.02_1     NVidia graphics card binary drivers for hardware OpenGL rendering
nvidia-drm-61-kmod-580.119.02.1403000_1 NVIDIA DRM Kernel Module
nvidia-kmod-580.119.02.1403000_1 kmod part of NVidia graphics card binary drivers for hardware OpenGL rendering
nvidia-settings-580.119.02     Display Control Panel for X NVidia driver
$

Original Reddit (Link): nvidia pkg update installs known broken version

Text from Original Reddit Poster:

Heads up: Was running 580.95.05 of nvidia driver/drm61/kmod.

Updates appeared....

New: 580.119.02_1

Turns out this is known broken in the nvidia space, causes items to be rendered then not, then back (very wild flicker of content).

Have put the older release back from my pkg cache as the pkg server had the older versions deleted.

Not sure who maintains the external nvidia package at the pkg server. Would like to let them know to roll it back.
 
When a new version of a port is available, the pkg server deletes the current version in order to build and distribute the new version.

I guess T-Aoki here was the maintainer of nvidia driver ports.
 
First of all, I'm not at all watching Reddit.
So anything posted to Reddit alone shouldn't ping me.

And quarterly (currently 2026Q1) wouldn't accept any updates except:
  • CVE is noted on Release Highlights
  • Build failure happened (basically) on main branch of base (aka -Current) as of the updates on base
  • Runtime failure happened (basically) on main branch of base (aka -Current)as of the updates on base
Otherwise, merging to quarterly needs explicit approval of portmgr.

So unless anyone reports the issue with detailed OS version, driver version and how the person installed (ports or pkg, if pkg, used kmods repo or not), GPU used and how the monitor is connected (DP? HDMI? or else?), and upgrading to the version on latest (aka main) branch of ports fixes the issue or not on Bugzilla, we cannot request approval to portmgr.

Report to request merge would be preferred on the PR upgraded on latest branch (for 580.126.09, PR 292454).

If the breakage is neither on main (or any supported versions) of base nor anything provided as source codes by nvidia, we can do nothing and need to wait for nvidia to fix the issue.
And as there is known issue even on 580.126.09 as commented on PR 292454, we would upgrade ports when newer version is released by nvidia ASAP (best effort basis, as we are 100% volunteers) and this is the only thing what we can do if the breakage is in binary only part.
 
And note that I'm searching Bugzilla, Phabricator and freebsd-ports ML with keyword "nvidia" daily (for Bugzilla, basically new, open and in-progress ones), but not here. But thankfully Bugzilla emails me when anything other than by me are updated for PRs I'm CC'ed (once I post something on any PR, I'm automatically CC'ed).
When I respond here like this time is the cases the thread appears with new post on "Latest posts".
 
Additional note.
The flickering issue seem to be Wayland specific, which I cannot try with some reason (most specifically, I can never succeeded to make Japanese input method running, which is mandatory for me).

And as nvidia does NOT officially stated supports for XLibre, tested on Xorg only (as anything provided in binary only is needed to be fixed by nvidia).

I'm basically following the latest stable branch of base, so tested on stable/15, amd64.
But when I find anything seemingly affect is committed on main (or build/runtime failure is reported on main via Bugzilla or freebsd-ports ML), try main, too, and attempt to fix the issue.
 
T-Aoki one quick aside--I can get Japanese input on Wayland with labwc, a Wayland version of openbox, and fcitx5 (though it's quite iffy with dwl, a dwm equivalent.) See my https://srobb.net/jpninpt.html#wayland.

As for Nvidia, I use latest, as far as packages, and often, when there's an upgrade, it gives me issues. If it does, I first update ports to most recent, then I upgrade nvidia-drm-kmod using the port. For several years this has always solved any Nvidia issue for me. I don't report them as bugs because I'm using latest, rather than quarterly for packages and it's such a simple fix that to me it isn't a bug, just knowing that there may be a mismatch with the package. The only issue I've had with this method was when I forgot to update ports and until I remembered, I couldn't figure out what was wrong. I may have posted about it here at the time.
Anyway updating nvidia-drm-kmod through ports will pull in any other packages needed for me, at least so far. :)
 
T-Aoki said:
The flickering issue seem to be Wayland specific
Click to expand...

I am NOT using Wayland - I am using Xorg.

What is the recommended fix for this? I (guess?) I would prefer to go backwards to the previously working drivers?

Apparently I picked this up this NVIDIA change as part of an (over 300 package) change to my system. I guess I need to start pkg locking all of the NVIDIA drivers on my NVIDIA based systems again?
 
The Nvidia proprietary driver version 580.119.02 introduced the following issues when using x11 compositors such as picom with the glx backend.
  1. Heavy keyboard input lag in applications such as rofi. The input lag is not present in google-chrome stable. (Edit: YES)
  2. Application glitching where elements flicker between being rendered and not rendered, most obvious in virt-manager. (Edit: YES)
  3. Mouse hovering over menus resulting in multiple highlighted elements, often glitching back and forth between selected elements, when no user input is being done. Most obvious in virt-manager and sometimes in the thunar right click context menu when hovering over menu items. (Edit: YES)
This issue is not present in,
  1. Wayland sessions.
  2. x11 sessions with the picom backend render set to xrender.
  3. x11 sessions with picom compositor disabled.
  4. Nvidia driver version 580.105.08
==> Original Bug Report here (link)

The input keyboard bug is realllllyyy aweful -- feels like you are typing at 300 baud
 
CShell said:
What is the recommended fix for this? I (guess?) I would prefer to go backwards to the previously working drivers?
Click to expand...
Rolling back official ports tree surely let users that had issues and 580.119.02 and later fixes the issue, so rolling back the official ports tree is not at all our option.

Use ports instead of pkg for nvidia driver ports, using git to maintain ports tree. git would allow you to roll back your local ports tree by checking out known-to-work commit. Or take diff within working version (just before 580.119.02 is committed, 011d8882ade1f40a4f39e08ad9d183733cc43fd4) and apply it IN REVERSE.
Once you have local clone of git repo for ports tree at /usr/ports, you can:
git diff 011d8882ade1f40a4f39e08ad9d183733cc43fd4 -- x11/nvidia-driver/ > somewhere/you/want/to/save/diff
git diff 011d8882ade1f40a4f39e08ad9d183733cc43fd4 -- x11/nvidia-kmod/ >> somewhere/you/want/to/save/diff
git diff 011d8882ade1f40a4f39e08ad9d183733cc43fd4 -- graphics/nvidia-drm-61-kmod/ >> somewhere/you/want/to/save/diff

then (to be sure, invoke dry-run before actually patching and see it goes fine)

gpatch -p1 -R -E --dry-run --verbose -i somewhere/you/want/to/save/diff

if OK, run without --dry-run.
I recommend gpatch (from devel/patch) here, as patch(1) in base has some glitches when new file and/or directory is created.

Now, you can build should-be-working version locally.

You also need src tree that (to be safest) 100% match your running kernel, too, to build kernel modules.
 
CShell said:
The Nvidia proprietary driver version 580.119.02 introduced the following issues when using x11 compositors such as picom with the glx backend.
  1. Heavy keyboard input lag in applications such as rofi. The input lag is not present in google-chrome stable. (Edit: YES)
  2. Application glitching where elements flicker between being rendered and not rendered, most obvious in virt-manager. (Edit: YES)
  3. Mouse hovering over menus resulting in multiple highlighted elements, often glitching back and forth between selected elements, when no user input is being done. Most obvious in virt-manager and sometimes in the thunar right click context menu when hovering over menu items. (Edit: YES)
This issue is not present in,
  1. Wayland sessions.
  2. x11 sessions with the picom backend render set to xrender.
  3. x11 sessions with picom compositor disabled.
  4. Nvidia driver version 580.105.08
==> Original Bug Report here (link)

The input keyboard bug is realllllyyy aweful -- feels like you are typing at 300 baud
Click to expand...
Picom is known to NOT working properly with nvidia drivers 580.119.02 and later and nvidia seems to working on fixing it, but not yet in 580.126.09.
As you can see with the link above, it's not FreeBSD specific.

And I've not encountered the issue using Mate DE + Compiz (using overlay provided by Ken DEGUCHI). Compiz is a compositor derived from Compton like Picom, but different fork.
 
CShell said:
The nvidia-drm-kmod-580.119.02 IS the broken driver. Trying to go somewhere else.
Click to expand...
Having this similar problem on 15.0 on a Skylake system. I used that old driver in FreeBSD 14.2. Everything graphics-related worked with no problems.
But ce the driver is now marked broken for a reason unclear to me. The kmod-61 works too but with a 13 secomds delay at the start of X.org. A cursor-like white rectangle is shown at this point. I have no idea what it's trying and why. Everything already works. We can dismiss any detection procedures... 13 seconds extra boot-time for nothing is unacceptable. (It's already sad for only a graphics-driver and not even the switching to a different resolution because that already happens at loading the kernel module, but that's my opinion)
 
If you're NOT unlucky, adding below in your /etc/make.conf with 2026Q1 ports tree could help (easier if you're lucky, as I've never tried it to go backward). This way, you don't need to patch ports tree. Latest (aka main) branch of ports tree is OK, too.

Of course, you need ports tree and src tree as already mentioned.

Code: 
NVIDIA_OVERRIDE_VERSION= 580.105.08

.if ${.CURDIR:M/usr/ports/x11/nvidia-driver*} && defined (NVIDIA_OVERRIDE_VERSION)
  DISTVERSION=    ${NVIDIA_OVERRIDE_VERSION}
  NO_CHECKSUM=    YES
.endif

.if ${.CURDIR:M/usr/ports/x11/nvidia-kmod*} && defined (NVIDIA_OVERRIDE_VERSION)
  DISTVERSION=    ${NVIDIA_OVERRIDE_VERSION}
  NO_CHECKSUM=    YES
.endif

.if ${.CURDIR:M/usr/ports/x11/linux-nvidia-libs*} && defined (NVIDIA_OVERRIDE_VERSION)
  DISTVERSION=    ${NVIDIA_OVERRIDE_VERSION}
  NO_CHECKSUM=    YES
.endif

## graphics/nvidia-drm-*-kmod supports 550 series and above only.
## Don't attempt to override before 550 series!
.if ${.CURDIR:M/usr/ports/graphics/nvidia-drm-*-kmod*} && defined (NVIDIA_OVERRIDE_VERSION)
  NVIDIA_DISTVERSION=    ${NVIDIA_OVERRIDE_VERSION}
  NO_CHECKSUM=    YES
.endif

.if ${.CURDIR:M/usr/ports/graphics/nvidia-drm-kmod*} && defined (NVIDIA_OVERRIDE_VERSION)
  DISTVERSION=    ${NVIDIA_OVERRIDE_VERSION}
  NO_CHECKSUM=    YES
.endif
 
MG said:
Having this similar problem on 15.0 on a Skylake system. I used that old driver in FreeBSD 14.2. Everything graphics-related worked with no problems.
But since the driver is broken for a reason unclear to me. The kmod-61 works too be with a 13 secomds delay at the start of X.org. (A cursor-like whie rectangle is shown at this point. I have no idea what it's trying and why. Everything already works. We can dismiss any detection procedures... 13 seconds extra boot-time for nothing is unacceptable.
Click to expand...
Again, 580.119.02 and later are known to fix different issues for others. So rolling back official ports tree is NOT an option. Fix by rolling back for you means breakages for others.
 
T-Aoki said:
Again, 580.119.02 and later are known to fix different issues for others. So rolling back official ports tree is NOT an option. Fix by rolling back for you means breakages for others.
Click to expand...
Not rolling back anything. The old driver version that I used on 14.2 is now broken and any new driver has this delay or doesn't work at all.
Is there any consistent howto for Nvidia and FreeBSD 15? What's different now compared to 14.? releases?
 
MG said:
Not rolling back anything. The old driver version that I used on 14.2 is now broken and any new driver has this delay or doesn't work at all.
Is there any consistent howto for Nvidia and FreeBSD 15?
Click to expand...
Never experienced such a delays related to Xorg nor nvidia drivers, but mis-configuration in libinput and/or evdev. Cannot reproduce on current ports tree.
 
T-Aoki said:
Never experienced such a delays related to Xorg nor nvidia drivers, but mis-configuration in libinput and/or evdev. Cannot reproduce on current ports tree.
Click to expand...
It's a 15.0 GENERIC system built from source with a recent portstree.
T-Aoki said:
Never experienced such a delays related to Xorg nor nvidia drivers, but mis-configuration in libinput and/or evdev. Cannot reproduce on current ports tree.
Click to expand...
This is a custom source build, but for now still 15.0 RELEASE and a recent portstree. It already builds entirely offline. Problem is that I dont know where to look. So many option t-sections that trying out all of them can't be done alone... I may find it while continuing to develop and do other things on this system.
 
CShell said:
The Nvidia proprietary driver version 580.119.02 introduced the following issues when using x11 compositors such as picom with the glx backend.
  1. Heavy keyboard input lag in applications such as rofi. The input lag is not present in google-chrome stable. (Edit: YES)
  2. Application glitching where elements flicker between being rendered and not rendered, most obvious in virt-manager. (Edit: YES)
  3. Mouse hovering over menus resulting in multiple highlighted elements, often glitching back and forth between selected elements, when no user input is being done. Most obvious in virt-manager and sometimes in the thunar right click context menu when hovering over menu items. (Edit: YES)
This issue is not present in,
  1. Wayland sessions.
  2. x11 sessions with the picom backend render set to xrender.
  3. x11 sessions with picom compositor disabled.
  4. Nvidia driver version 580.105.08
==> Original Bug Report here (link)

The input keyboard bug is realllllyyy aweful -- feels like you are typing at 300 baud
Click to expand...
I've never had any of these problems.
Note was never able to make wayland work.

picom.conf
Code: 
# --- General Settings ---
backend = "glx";
# backend = "xrender";
glx-no-stencil = true;
glx-copy-from-front = false;
vsync = true;
daemon = true;
use-damage = false;

# --- Opacity ---
active-opacity = 1.0;
inactive-opacity = 0.975;
inactive-opacity-override = false; # Changed to false for better readability
frame-opacity = 1.0;

# Detect _NET_WM_WINDOW_OPACITY to avoid issues with some apps
detect-client-opacity = true;

# --- Fading ---
fading = true;
fade-in-step = 0.05;
fade-out-step = 0.05;
fade-delta = 6;

# --- Shadows ---
shadow = true;
shadow-radius = 12;
shadow-offset-x = -12;
shadow-offset-y = -12;
shadow-opacity = 0.7;

# --- Exclusions ---
# Prevents transparency/shadows on specific apps
focus-exclude = [
    "class_g = 'Cairo-clock'",
    "class_g = 'slop'"
];

# --- Window Types ---
wintypes:
{
  tooltip = { fade = true; shadow = true; opacity = 0.95; focus = true; };
  dock = { shadow = false; clip-shadow-above = true; }
  dnd = { shadow = false; }
  popup_menu = { opacity = 1.0; }
  dropdown_menu = { opacity = 1.0; }
};

cat 20-nvidia.conf
Code: 
Section "Device"
   Identifier     "Device0"
   Driver         "nvidia"
   Option "PrimaryGPU" "yes"
   Option         "RenderAccel" "true"
   VendorName     "NVIDIA Corporation"
   Option "AccelMethod" "EXA"
EndSection
 
One of what I've done when I've experienced input delays / duplicates / ... is putting below in my /etc/sysctl/conf and try-and-error switching uncommented configuration. (Unrelated with nvidia drivers.)
Code: 
## evdev event generation settings for keyboards and mice.
## Set correlated bits to enable.
## The value is defined in sys/dev/evdev/evdev.h as
##    #define    EVDEV_RCPT_SYSMOUSE    (1<<0)
##    #define    EVDEV_RCPT_KBDMUX    (1<<1)
##    #define    EVDEV_RCPT_HW_MOUSE    (1<<2)
##    #define    EVDEV_RCPT_HW_KBD    (1<<3)
##    extern int evdev_rcpt_mask;
## respectively.
#
# kern.evdev.rcpt_mask=1    # bit0 (1<<0), via sysmouse
# kern.evdev.rcpt_mask=2    # bit1 (1<<1), via kbdmux
# kern.evdev.rcpt_mask=4    # bit2 (1<<2), direct USB mouse (ums)
# kern.evdev.rcpt_mask=8    # bit3 (1<<3), direct keyboard (atkbd and ukbd)
# kern.evdev.rcpt_mask=5    # Both bit2 and 0 (sysmouse and ums, no kbd)
# kern.evdev.rcpt_mask=6    # Both bit2 and 1 (ums and kbdmux)
# kern.evdev.rcpt_mask=7    # Bits2, 1, and 0 (ums, kbdmux and sysmouse)
# kern.evdev.rcpt_mask=9    # Bits3 and 0 (direct keyboard and sysmouse)
# kern.evdev.rcpt_mask=10    # Both bit3 and 1 (direct kbd and kbdmux)
# kern.evdev.rcpt_mask=11    # Bits3, 1, and 0 (HW kbd, kbdmux, sysmouse)
kern.evdev.rcpt_mask=12    # Both bit3 and 2 (direct kbd and ums) default
# kern.evdev.rcpt_mask=13    # Bits 3, 2 and 0 (HW kbd, ums and sysmouse)
# kern.evdev.rcpt_mask=14    # Bits 3, 2 and 1 (HW kbd, ums and kbdmux)
# kern.evdev.rcpt_mask=15    # All 4 bits
Current default is 12, if I recall correctly.
 
You must log in or register to reply here.
Back
Top