NVIDIA
RTX 5090 FE doesn't support triple monitor display at high refresh rates which work under Windows
NVIDIA Open GPU Kernel Modules Version
570.144, 575.51.02 Beta
Please confirm this issue does not happen with the proprietary driver (of the same version). This issue tracker is only for bugs specific to the open kernel driver.
- [x] I confirm that this does not happen with the proprietary driver package.
(NOTE: the proprietary driver doesn't support the 5090 so not applicable)
Operating System and Version
CachyOS April 2025
Kernel Release
6.14.5
Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.
- [x] I am running on a stable kernel release.
Hardware: GPU
GPU 0: NVIDIA GeForce RTX 5090 (UUID: GPU-50649b99-868e-32a7-99da-2d69ca3ae9b7)
Describe the bug
Possibly related:
- https://github.com/NVIDIA/open-gpu-kernel-modules/issues/851
- https://github.com/NVIDIA/open-gpu-kernel-modules/issues/816
I am using the RTX 5090 FE with a triple monitor display configuration running KDE Plasma 6.3.4 Wayland (same problem happens for X11).
I have found that certain configurations of the monitors fail under Linux when the same configuration otherwise works fine under Windows.
Specifically, I am trying to run the following:
- Asus PG348Q: 3440x1440 @ 100Hz 1.2a
- Asus PG27AQDP: 2560x1440 @ 480Hz DP 1.4
- Asus PG32UCDP: 3840x2160 @ 240Hz HDMI 2.1
On Windows 11 this configuration works fine:
On Linux, the configuration fails. The failure behavior is a little bit different depending on whether I am running Plasma Wayland or Plasma X11.
For Plasma Wayland:
If I have all three monitors set as above when I boot into the desktop, the display driver just stops refreshing the displays of the monitors.
The system looks like it has frozen but if I login through ssh, everything responds as normal.
There are no error messages about the display driver shown in dmesg or any other indication that something has gone wrong.
If I explicitly disable one of the displays with:
echo off > /sys/class/drm/card0-DP-2/status
then eventually the system will "recover" and the display starts refreshing again. If I toggle the port back on again with echo on > ... it "freezes" again (and can still be recovered again).
For Plasma X11:
If I have all three monitors set as above, Plasma simply refuses to set the refresh rate of one of the monitors to its maximum setting. The displays don't freeze though.
If I try to go into the display configuration and manually force the refresh rate higher, it looks like it works but does nothing. If I check the refresh rate with any tool, it shows unchanged, and if I go back into the display configuration it shows unchanged there also.
Configurations I've found which do work:
- Asus PG348Q: 3440x1440 @ 100Hz 1.2a
- Asus PG27AQDP: 2560x1440 @ 240Hz DP 1.4
- Asus PG32UCDP: 3840x2160 @ 240Hz HDMI 2.1
or
- Asus PG348Q: 3440x1440 @ 100Hz 1.2a
- Asus PG27AQDP: 2560x1440 @ 360Hz DP 1.4
- Asus PG32UCDP: 3840x2160 @ 120Hz HDMI 2.1
There should be enough resources for the max refresh rate configuration since the PG27AQDP @ 480Hz and the PG32UCDP @ 480Hz should only be using a single display head, confirmed by nvidia settings:
To Reproduce
Try using the following triple monitor display configuration under Plasma Wayland or X11:
- Asus PG348Q: 3440x1440 @ 100Hz 1.2a
- Asus PG27AQDP: 2560x1440 @ 480Hz DP 1.4
- Asus PG32UCDP: 3840x2160 @ 240Hz HDMI 2.1
Bug Incidence
Always
nvidia-bug-report.log.gz
More Info
No response
Thank you for reporting issue, I have filed a bug 5301413 internally for tracking purpose. Shall check for similar display internally and attempt for local repro.
I do have the exact same issue with the RTX 5090 and the following monitors:
- Asus PG32UCDM (HDMI 2.1, 240Hz)
- ASUS PG27AQ (DP 1.4, 60Hz)
- AOC U27G3X (DP 1.4, 160Hz)
If I turn off or disable the AOC one Wayland works fine on the two Asus ones, but as soon as I turn the AOC one on it seems to freeze until I turn it off again, then it runs fine again. X11 shows all three monitors but I can't seem to set the refresh rate as already mentioned by @silvanshade
@silvanshade can you try to unset enable_overlay_layers module parameter of nvidia-modeset.ko using command : rmmod nvidia-drm nvidia-modeset && modprobe nvidia-modeset enable_overlay_layers=0 && modprobe nvidia-drm
@silvanshade can you try to unset enable_overlay_layers module parameter of nvidia-modeset.ko using command : rmmod nvidia-drm nvidia-modeset && modprobe nvidia-modeset enable_overlay_layers=0 && modprobe nvidia-drm
@nmahale Is this expected to fix the issue? Can you explain why changing this would have an effect here?
@silvanshade can you try to unset enable_overlay_layers module parameter of nvidia-modeset.ko using command : rmmod nvidia-drm nvidia-modeset && modprobe nvidia-modeset enable_overlay_layers=0 && modprobe nvidia-drm
@nmahale Is this expected to fix the issue? Can you explain why changing this would have an effect here?
It is anticipated that the solution will address the issue. The hardware is equipped with only eight physical wins (pre-composition pipes). To drive higher resolutions such as 4K@240Hz, each layer necessitates two physical wins. Each head or CRT supports two layers: 1) Main/Primary and 2) Overlay. Therefore, with overlay layer support, a total of ten physical wins are required to achieve the triple monitor configuration at a high refresh rate. Disabling the overlay support reduces the number of physical wins to five, making the triple monitor configuration feasible.
Asus PG348Q: 3440x1440 @ 100Hz 1.2a -> 2 layers -> 2 phy-wins. Asus PG27AQDP: 2560x1440 @ 480Hz DP 1.4 -> 2 layers -> 4 phy-wins Asus PG32UCDP: 3840x2160 @ 240Hz HDMI 2.1 -> 2 layers -> 4 phy-wins.
Thanks for the explanation.
I have tested this by adding nvidia-modeset.enable_overlay_layers=0 as a kernel parameter and it seems to work. I can activate all three monitors at their highest refresh rates under Wayland now without the display freezing.
I have two questions then:
- What is the downside of having overlay layers disabled?
- Could the driver be modified to automatically detect this configuration and disable overlays automatically? I'm guessing this must be similar to what is happening on Windows for it to be able to work there without any intervention?
- If (2) is not feasible for some reason, could the driver at least be modified to emit a warning via dmesg with a hint to try this setting, so if a user encounters this frozen display state they might at least get some insight into what to do?
Thanks for the explanation.
I have tested this by adding
nvidia-modeset.enable_overlay_layers=0as a kernel parameter and it seems to work. I can activate all three monitors at their highest refresh rates under Wayland now without the display freezing.I have two questions then:
- What is the downside of having overlay layers disabled?
DRM overlay planes will not be available. VDPAU overlay presentation is not possible. GLX overlay will not be available.
- Could the driver be modified to automatically detect this configuration and disable overlays automatically? I'm guessing this must be similar to what is happening on Windows for it to be able to work there without any intervention?
We are actively working on a solution, but due to the extensive code refactoring required, an exact specific timeline cannot be committed at this time.
- If (2) is not feasible for some reason, could the driver at least be modified to emit a warning via dmesg with a hint to try this setting, so if a user encounters this frozen display state they might at least get some insight into what to do?
Certainly, I will investigate this matter and determine the appropriate course of action.
@nmahale if you intended to respond to the quoted text, the response appears to be missing.