BUG REPORT: RTX 5070 laptop (nvidia-open 595.84, hybrid mux): external displays not detected in Intel mode; internal panel freezes/unresponsive in NVI

Graphics / Linux Linux
1

System info

  • GPU: NVIDIA GeForce RTX 5070 (laptop, hybrid mux design)
  • Driver: nvidia-driver-595-open, version 595.84
  • Kernel: 7.0.0-30-generic
  • Kernel command line: i915.force_probe=!7d67 xe.force_probe=7d67 nvidia.NVreg_PreserveVideoMemoryAllocations=1 nvidia_drm.modeset=1 pcie_aspm=off (Intel iGPU bound via xe, device id 7d67)
  • OS: Linux Mint 22.3 - Cinnamon 64-bit
  • Internal panel: 2560x1600 eDP, native 240Hz (likely DSC given resolution/refresh combination)
  • External output tested: HDMI

Bug 1: External displays not recognised when connected, running in Intel mode

Symptom: Using prime-select intel - when connecting an external monitor via HDMI, the display is not listed in the Mint display settings or visible in the output of xrandr -q.

After connecting the display running journalctl -k | grep -iE "drm|hdmi|dp aux" shows no entries with a recent timestamp.

Bug 2: Internal display refresh issues, running in NVIDIA mode

Symptom: On boot, the login screen (and later, the desktop) renders once but then becomes completely visually unresponsive on the internal panel — no repaint occurs — while input is still being processed underneath (e.g. typing in the password field, moving the mouse cursor). Switching to a TTY (Ctrl+Alt+F1) and back to X (Ctrl+Alt+F7) forces a full repaint showing the accumulated state of prior input. Login itself succeeds; only the visual refresh is broken until the next VT switch.

  • An external HDMI display attached at the same time renders its portion of the desktop correctly and continuously — only the internal panel is affected.
  • Forcing a lower internal-panel mode (2560x1440@60Hz) changes but does not fix the behaviour — some responsiveness returns but with very high input-to-display latency. Other non-native resolutions produce varying tearing/unresponsiveness.
  • Native internal resolution/refresh is 2560x1600@240Hz.

First occurred: After a routine system update. Note the update log does not show an nvidia-driver/nvidia-dkms package change directly — it shows kernel-header/tool package bumps (linux-libc-dev, linux-tools-common 6.8.0-124 → 6.8.0-134) alongside mesa, libdrm and xserver-xorg-core updates. Given Mint’s Update Manager handles kernel image installs separately from its APT log, it’s possible an actual kernel change is the real trigger and isn’t reflected in that log at all.

Troubleshooting already done (all with no effect on the freeze):

  • Downgrading nvidia-driver-open across several branches (575-open made the internal panel worse — completely unresponsive at any resolution, rather than freezing-with-input-processed).
  • options nvidia_modeset vblank_sem_control=0 (modprobe.d, initramfs rebuilt) — no change.
  • options nvidia_modeset conceal_vrr_caps=1 (modprobe.d, initramfs rebuilt) — no change.

Logs checked:

  • journalctl -b -k | grep -i xid — no NVIDIA Xid errors (only an unrelated r8169 NIC “XID” chip-revision log line).
  • journalctl -b | grep -iE "flip event|idling display engine|atomic modeset" — no output.
  • journalctl -b | grep -i nvidia — clean driver load, only notable entries are:
    • nvidia-persistenced initially failing to query devices before succeeding on a systemd retry (looks cosmetic/race-related, not obviously connected).
    • Three early boot-time errors:
    [drm:__nv_drm_nvkms_gem_obj_init [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000200] Failed to get memory pages for NvKmsKapiMemory 0x...

(possibly benign/unrelated — an identical line appears in [NVIDIA/open-gpu-kernel-modules#1290](https://github.com/NVIDIA/open-gpu-kernel-modules/issues/1290), also on driver 595.84 with a hybrid dGPU+iGPU laptop, where the reporter also flags it as likely unrelated to their main issue.)

Possibly related upstream report: NVIDIA/open-gpu-kernel-modules#1290 — same driver build (595.84), hybrid mux laptop (RTX 5090 + Ryzen iGPU there vs. RTX 5070 + Intel iGPU here), describes a silent hang (no Xid/NVRM error) where an atomic commit’s dma_fence never signals, permanently wedging the commit pipeline — recoverable only by hard power-off in their case. The general shape (no logged fault, GPU+iGPU both active, commit/flip pipeline stuck) is very similar to what’s described here, though the specific output path (reverse-PRIME to the iGPU-driven display vs. our directly-mux’d internal panel) differs.

Question for the forum: Given no Xid, no flip-timeout, and no VRR-related log output, is there a way to get more verbose diagnostics out of nvidia-modeset’s atomic commit path specifically for the internal/eDP head, to confirm whether this is the same commit-never-completes class of bug as #1290?

nvidia-bug-report.log.gz (1.7 MB)