Two 4K@240 Hz DSC displays use all 4 heads on RTX 5080; a third display is rejected (works on Windows)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 38/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- c, linux
- Domain
- backend, operating-systems
Research direction
Start by inspecting the NVIDIA DRM/KMS atomic commit path and display head allocation for DSC modes; the report identifies /proc/driver/nvidia-modeset/heads and GNOME/mutter’s failed atomic commit as evidence. Compare head allocation for two 4K@240 Hz DSC displays with and without the third display, then determine why the commit returns EINVAL and whether the driver can report the constraint.
Written by the indexing model from the issue text.
Description
NVIDIA Open GPU Kernel Modules Version
615.78.08 (open kernel modules)
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.
- I confirm that this does not happen with the proprietary driver package.
Operating System and Version
Arch Linux, kernel 7.2.11-arch1-1
Kernel Release
7.2.11-arch1-1
Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.
- I am running on a stable kernel release.
Hardware: GPU
NVIDIA GeForce RTX 5080 (GB203, 10de:2c02), PNY
Describe the bug
Disclaimer: This ticket was Co-Authored with Claude Opus 5.5 to help me investigate the various pieces. I don't have enough knowledge to debug all those aspects by myself.
With two LG UltraGear+ 4K monitors at 240 Hz over DisplayPort (DSC), the driver appears to use all four display heads. Any additional display then fails to light up, even at 60 Hz, and the compositor's atomic commit fails with EINVAL.
On Windows, the same GPU, monitors, cables and ports run all four displays at full refresh at the same time:
- 2× LG UltraGear+ 3840x2160 @ 240 Hz (DP)
- MSI MAG 273Q X24 2560x1440 @ 240 Hz (DP)
- LG TV 3840x2160 @ 120 Hz (HDMI)
The 4K@240 mode uses a 2332.66 MHz pixel clock (from the EDID DisplayID detailed timing). On Linux, each such display appears to be driven with two heads (2Head1OR), while the Windows driver evidently doesn't need to.
Displays
┌────────────────────┬────────────────────────────────┬───────────────────────┐
│ nvidia-modeset dpy │ Monitor │ Target mode │
├────────────────────┼────────────────────────────────┼───────────────────────┤
│ DP-0 │ MSI MAG 273Q X24 │ 2560x1440 @ 240 Hz │
├────────────────────┼────────────────────────────────┼───────────────────────┤
│ DP-2 │ LG ULTRAGEAR+ (2025 unit) │ 3840x2160 @ 240.08 Hz │
├────────────────────┼────────────────────────────────┼───────────────────────┤
│ DP-4 │ LG ULTRAGEAR+ (2024 unit) │ 3840x2160 @ 240.08 Hz │
├────────────────────┼────────────────────────────────┼───────────────────────┤
│ HDMI-0 │ LG TV (unplugged during tests) │ 3840x2160 @ 120 Hz │
└────────────────────┴────────────────────────────────┴───────────────────────┘
Results
┌────────────────────────────────────┬────────────────────────────────────────────┐
│ Configuration │ Result │
├────────────────────────────────────┼────────────────────────────────────────────┤
│ LG 240 + LG 240 + MSI 240 + TV │ ✗ second LG rejected, falls back to 144 Hz │
├────────────────────────────────────┼────────────────────────────────────────────┤
│ LG 240 + LG 144 + MSI 240 │ ✓ │
├────────────────────────────────────┼────────────────────────────────────────────┤
│ LG 240 + LG 240 (MSI disabled) │ ✓ both at 240 Hz │
├────────────────────────────────────┼────────────────────────────────────────────┤
│ LG 240 + LG 240 + MSI @ 60 Hz │ ✗ MSI cannot be enabled │
├────────────────────────────────────┼────────────────────────────────────────────┤
│ All four at max refresh on Windows │ ✓ │
└────────────────────────────────────┴────────────────────────────────────────────┘
Swapping which LG is active shows that both monitors, cables and ports work at 4K@240 individually.
Evidence
/proc/driver/nvidia-modeset/heads with both LGs at 240 Hz, right after enabling the MSI failed:
head 0 : inactive
head 1 : LG Electronics LG ULTRAGEAR+ (DP-4) 3840 x 2160 @ 240.0844 Hz 30bpp 4:4:4 AdaptiveSync
head 2 : LG Electronics LG ULTRAGEAR+ (DP-2) 3840 x 2160 @ 240.0844 Hz 30bpp 4:4:4 AdaptiveSync
head 3 : inactive
Two heads are reported inactive, yet a third display can't be driven even at 60 Hz. My guess is that heads 0 and 3 are the hidden second heads of the LG displays.
Compositor (GNOME/mutter, Wayland) log when the commit is rejected:
KMS: Posting primary plane composite update for CRTC 1072 (/dev/dri/card1) to DP-3
KMS: [atomic] KMS update failed: drmModeAtomicCommit: Invalid argument
Page flip failed: drmModeAtomicCommit: Invalid argument
The kernel log has no NVRM or nvidia-modeset message explaining the rejection.
Driver configuration: nvidia_drm.modeset=Y, fbdev=Y. No custom registry keys.
To Reproduce
- Connect two 3840x2160@240 Hz DSC displays and one more display via DP.
- In a Wayland session, set both 4K displays to 240 Hz.
- Try to enable the third display at any refresh rate. The atomic commit fails with EINVAL.
Bug Incidence
Always
nvidia-bug-report.log.gz
More Info
Expected behavior
The same configuration as on Windows works: both 4K displays at 240 Hz plus additional displays. If two heads per 4K@240 display really is a hardware requirement, the driver should explain why it's rejecting the mode instead of failing silently with EINVAL.
The Windows driver used in the working setup is: GeForce 617.42 WHQL
- Dominant language
- C
- Stars
- 17.5k
- Forks
- 1.9k
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from NVIDIA/open-gpu-kernel-modules
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
NVIDIA/open-gpu-kernel-modules#1479 · 2 comments ·
Maintainers usually reply within 1 day
-
PlatformRequestHandler: missing !bInit guard on bSystemParamLimitUpdate causes NV_ERR_INVALID_DATA at bootPossibly taken @SammyTourani claimed this 37 days ago. Open
Difficulty 1/5 Under an hour Newbie friendliness 88/100
NVIDIA/open-gpu-kernel-modules#1360 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
NVIDIA/open-gpu-kernel-modules#1343 · 3 comments ·
Maintainers usually reply within 1 day
-
HKC G27H7Pro redundant long-HPD loop after DisplayPort link training (RTX 5060 Laptop, 610.57.04)Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
NVIDIA/open-gpu-kernel-modules#1323 ·
Maintainers usually reply within 1 day
-
build-problem
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
NVIDIA/open-gpu-kernel-modules#1155 · 1 comment ·
Maintainers usually reply within 1 day
All issues in NVIDIA/open-gpu-kernel-modules
Similar issues
-
Difficulty 2/5 Half a day Newbie friendliness 72/100
vercel-labs/scriptc#2910 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
darktable-org/darktable#22939 ·
Maintainers usually reply within 1 day
-
os: input_password leaves terminal echo disabled when reading failsPossibly taken @davlgd claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
armv7l: `close`, `unlink` and `chroot` pass the kernel their argument's addressPossibly taken @aoinoikaz claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
colbymchenry/codegraph#3223 ·
Maintainers usually reply within 1 day