The 595.99 driver landed on Linux with almost no fanfare, and that is a shame. The bug list in this release is the kind that has been quietly making life worse for Blackwell owners for months. Three of the patches target failure modes that people kept blaming on their monitors, their distros, or their power management. They were all NVIDIA. A fourth fix is forward-looking and matters if your distro is about to roll out kernel 7.x.
If you run an NVIDIA Blackwell GPU on Linux, this is the driver update you have been waiting for without knowing it. If your distro is moving to kernel 7.x, it is the driver you want on top. The release notes do not sell it, but the patch list is real, and the bugs it closes are the kind that ruin days.
What 595.99 actually fixes
Four patches ship in 595.99 that matter to anyone running Blackwell on a modern distro. The first three target specific failure modes. The fourth protects you against boot failures on kernel 7.0 systems that have turned off the legacy framebuffer fallback.
- An output-scaling corruption bug in the open GPU kernel modules
- A resume-after-hibernate-then-suspend failure in the same modules
- A black screen when switching to a Linux virtual console via Ctrl+Alt+F1 through F6
- A forward-compatibility fix for kernel 7.0 systems with DRM fbdev disabled
Most reviews lead with the kernel 7.0 fix. I think the three Blackwell patches are the bigger story. They are the ones that have been quietly breaking things for months.
The picture corruption that was never your monitor
If you run a lower-resolution desktop across a higher-resolution monitor, NVIDIA’s scaling path on Blackwell has been quietly wrong since launch. Output scaling matters for retro games, older apps that do not understand HiDPI (High Dots Per Inch, the modern high-density display standard), and remote-desktop sessions over a slow link. The bug was inside the open GPU kernel modules, which is the code path modern distros actually use.
If you have ever looked at a scaled desktop and noticed weird artifacts, stray lines through text, or a picture that just felt subtly off, the panel was not the problem. The driver was misrendering the framebuffer. Stop tolerating the glitch and install 595.99.
The wake-after-sleep sequence that should not have failed
The second bug bites anyone who uses hibernate. Hibernate, wake, suspend, wake again, and the resume could fail outright. NVIDIA traced it to the same open GPU kernel modules and patched it in 595.99.
Laptop users should pay attention here. Anyone who closes the lid, puts the machine to sleep, and wakes it back up at a desk has probably been hitting this without realizing it. With 595.99 installed, you stop having to think about which order you put the machine to sleep in. That alone is reason enough to update.
The console-switch black screen you thought was a panic moment
The third bug is one I have watched people panic through. Press Ctrl+Alt+F1 through F6 to switch to a Linux virtual console, which is your escape hatch when a graphical session dies. NVIDIA’s driver had a bug where switching consoles left you staring at a black screen instead of a usable login prompt.
The machine is fine. The kernel is running. The session is alive. The display just refused to show it. With 595.99, the escape hatch works the way you expect, and your rescue console is back.
The kernel 7.0 fix that buys you a working boot path
The fourth patch is for systems where DRM fbdev (Direct Rendering Manager framebuffer device, the kernel fallback that renders text during early boot) support is disabled. Newer kernels and hardened distros are turning that fallback off, which broke NVIDIA’s boot path. With 595.99, you keep a working console fallback path on kernel 7.0 systems even when fbdev is gone.
Why this matters now: more distributions are moving to kernel 7.x as their default. If yours is one of them, or will be soon, this driver ensures your machine boots into a working console instead of a blank screen. It is a quiet guarantee that tomorrow’s kernels will still work with your GPU.
Why NVIDIA shipped this as a maintenance release
Bug-fix-only releases get less press than feature drops, and that is part of why the changelog feels short. NVIDIA is doing the boring work of catching regressions and forward-compatibility gaps before they become the kind of bug that ends up in a Reddit thread. From a release-cadence perspective, maintenance releases are how NVIDIA signals to enterprise customers that the open GPU kernel modules are being treated as a first-class product rather than a stopgap while the proprietary driver catches up. For Blackwell users on Linux, that signal matters: it means the failure modes that have been quietly breaking your workflow for months are being tracked, not ignored.
The flip side is that maintenance releases do not get the same testing depth as feature releases. A patch that lands in 595.99 is one that NVIDIA considered stable enough to ship to the full install base, but it has not been on hundreds of millions of devices for months the way a feature release has. Watch your picture, your wake sequence, and your console-switching for the first week.
How to update without breaking your setup
I keep watching people reach for the .run installer first, and I keep watching them hit secure-boot issues or kernel-mismatch reinstalls a week later. Your distro’s package manager is almost always the better tool. It already integrates with your init system (the first process the Linux kernel launches, traditionally SysVinit or systemd, which manages service startup and shutdown), your kernel updates, and your secure boot chain. It also rolls in security patches without you having to check back.
The right path depends on your distro. For most people, it is one of these:
- On Ubuntu or a derivative, the Additional Drivers UI handles the proprietary driver cleanly
- On Fedora, Nobara, or Bazzite, install through the RPM Fusion repos for the official builds
- On a rolling-release distro like Arch or CachyOS, the nvidia package tracks upstream closely already
- For long-term-support distros, wait for your package repo to catch up before pulling the new release
The .run file is fine for the rare case where you need a specific upstream build that no distro ships. For the bulk of users it is the wrong default.
Trade-offs
Maintenance releases are not free in regression risk. NVIDIA ships patches for known issues, and sometimes a patch introduces a new failure mode that takes weeks to surface. The Blackwell scaling fix in particular touches a hot path, and a small number of users have reported subtle output quirks after the first 595.99 builds. Watch your picture quality for the first week after updating.
Switching to the distro-package driver is not free in flexibility. If you have been running the .run installer to pin a specific version, migrating means letting the package manager own the driver. You give up manual version pinning, and you accept your distro’s update cadence.
The kernel 7.0 fix is forward-looking and not free in early-adopter risk. Run a full update before you assume your boot path is solid, and confirm the driver version matches what you expect.
If scaling corruption, wake-after-sleep failures, or console-switch black screens have been ruining your days, install 595.99, reboot, and stop troubleshooting before you even start. The driver is the fix.