The driver release many NVIDIA fans have been waiting on is here today. NVIDIA released the NVIDIA 555.42.02 Beta driver with some necessary upgrades for Wayland support.
Since it's a Beta driver, it should go without saying that there may still be some lingering issues and bugs. This is for testing, but it shouldn't be too long before NVIDIA push out a stable driver with a small version number bump for when it's ready for everyone. Not that this will stop you right? You all want to try it.
The main changes are:
- The GSP firmware is now used by default on all GPUs which support it. It can be disabled by setting the kernel module parameter `NVreg_EnableGpuFirmware=0`.
- Added support for the linux-drm-syncobj-v1 protocol for Wayland explicit sync in EGL.
- Added immediate presentation mode support to Vulkan Wayland WSI. This presentation mode instructs the compositors not to wait for a vertical blanking period to update the application's surface content, which may result in tearing.
- Removed support for Base Mosaic on GeForce, which was previously available only on select GPU boards with some motherboards, and limited to five display devices.
- Enabled HDMI 10 bits per component support by default; disable by loading nvidia-modeset with `hdmi_deepcolor=0`.
- Added an interactive prompt to nvidia-installer to allow selecting between the proprietary and open kernel modules, on systems where both kernel module types are supported.
- Added support for using EGL instead of GLX as the OpenGL ICD for NvFBC.
- Changed the minimum required Linux kernel version from 3.10 to 4.15.
The bug fixes:
- Fixed a bug that caused "Failed to apply atomic modeset" and "Flip event timeout" messages to be printed to the system log when a DRM client such as ddcutil drops "master" permissions while a framebuffer console is being initialized.
- Fixed a bug, when nvidia-drm is loaded with the fbdev=1 module parameter on some kernels, that caused incorrect colors to be displayed.
- Fixed a regression that led to Xid errors when loading the NVIDIA driver on some notebook systems with RTX 4xxx series GPUs.
- Fixed a bug that caused driver build failure when using separate kernel source and output directories on Linux v6.6 and later.
- Fixed a bug that incorrectly allowed `nvidia-smi -r` to reset the primary GPU when using the open kernel modules.
- Fixed a bug that caused vkGetPhysicalDeviceSurfaceSupportKHR to incorrectly report support for Wayland surfaces when nvidia-drm is not loaded with modeset=1.
- Fixed a bug that could cause the display to lock up when suspending on a kernel with CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER enabled with nvidia-drm loaded with modeset=1 and fbdev=1.
- Fixed a bug that could lead to a system hang and "Idling display engine timed out" messages when VT switching on an HDMI Fixed Rate Link (FRL) display.
See it on the NVIDIA website.
Let me know how you get on with it in the comments.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
FWIW, 555.42.02 is in the fedora-multimedia repo. Haven't really messed with it much (I'm still on 39; need to upgrade to 40 for explicit sync support), but I do see that nvidia-settings is still quite limited on Wayland... not that I really use it for anything, but it's an indicator that Wayland isn't quite a first class citizen yet.
0 Likes
I'm glad NVIDIA pushed the entire Linux Graphics Stack to implement explicit sync too. It makes all of our desktops better.
They dragged us down by 10 years, without supporting GDB, wayland, etc, amd intel always had that figured out, except nvidia, this is a good solution yes, but because of their lazyness we aren't using wayland from default since years
Why are you saying its because of their lazyness and not amd, intels and wayland lazyness? why should nvidia implement something that is legacy everywhere else and amd/intel not implement something that has been the standard for over 10 years and that they have already implemented on windows?
Because
A. Just because it's 10 years old doesn't mean it's legacy. In system development 10 years is pretty young.
B. Because "legacy" is legacy, because it has proven to be useful.
C. Because standardization, basically any standard is just legacy support for really popular systems.
0 Likes
A. Just because it's 10 years old doesn't mean it's legacy. In system development 10 years is pretty young.
B. Because "legacy" is legacy, because it has proven to be useful.
C. Because standardization, basically any standard is just legacy support for really popular systems.
It's legacy because every modern graphics api is designed with explicit sync in mind (such as vulkan) and every other operating system uses explicit sync. Isn't wayland supposed to be forward-thinking instead of choosing decades old solutions that are no longer the best solution? But besides that, why should nvidia implement something that is guaranteed to get replaced anyways? wayland, amd and intel should just step forward and do the inevitable instead of wasting time with an inferior solution.
Last edited by nnohonsjnhtsylay on 23 May 2024 at 11:31 pm UTC
0 Likes
Isn't wayland supposed to be forward-thinking instead of choosing decades old solutions that are no longer the best solution? But besides that, why should nvidia implement something that is guaranteed to get replaced anyways?See point B and C.
It's legacy because every modern graphics api is designed with explicit sync in mind (such as vulkan) and every other operating system uses explicit sync.That depends on your definition of "modern".
OpenGL is still actively maintained and in use by basically all Linux supporting software.
Indeed games don't use it, but games generally don't actively support Linux, are at the bleeding edge of graphics development and more willing to waste developer time configuring the explicit sinc.
Also you've a much lower view of legacy support than I do.
I argue that legacy support is good for sustainability, marketability and competition.
Sometimes dropping legacy support can be needed to move forward, but it shouldn't be a goal on itself.
Remember backwards compatibility is much easier than forward compatibility.
If I write software I can't predict what ridiculous new environments will be developed, but I can consider what was developed in the past and help them.
Nvidia has the fullest right to drop support for old software, but it will make a lot of people's life a lot more uncomfortable and they will complain and buy less Nvidia stuff, because they want to run their stuff.
0 Likes
Patreon
PayPal
See more from me