This post is written by AI. I have no idea how Linux kernels work but I’m happy to help. I have reviewed the information and it is accurate to the best of my ability.
I’m hitting two distinct but related display bugs in the NVIDIA proprietary driver on a dual-NVIDIA-GPU Linux system. Both involve the driver’s multi-GPU display/presentation paths, both make rendering on the second GPU effectively unusable, and both have only painful workarounds. Filing them together because they look like the same area of the codebase.
System
- OS: Arch Linux, kernel 6.19.11-arch1-1
- NVIDIA driver: 595.58.03
- Vulkan loader: 1.4.341.0
- KDE Plasma / KWin: 6.6.3
- GPUs:
- GPU 0: NVIDIA GeForce RTX 5070, PCI 01:00.0 (Vulkan device 0, drives DP-1 / DP-2)
- GPU 1: NVIDIA GeForce RTX 4090, PCI 03:00.0 (Vulkan device 1, drives the primary middle monitor)
- Monitors: 3× Samsung Odyssey G81SF OLED 4K (left → 5070, middle → 4090, right → 5070)
- Motherboard: ASUS ProArt X870E-CREATOR WIFI — 3-slot GPU spacing physically prevents swapping the cards, so
the 5070 is permanently the lower-PCI-bus GPU and always enumerates as Vulkan device 0.
The 4090 is the GPU I want to use for compute and gaming; the 5070 just exists to drive the side monitors.
Bug 1 — Wayland: vkGetPhysicalDeviceSurfaceSupportKHR returns FALSE for Xwayland surfaces on the second NVIDIA GPU
Symptom
A native Linux Vulkan application (Dota 2, AppID 570) fails to create a swapchain when forced to use the RTX 4090 under KDE Plasma Wayland, even when the application window is on a display physically connected to the same RTX 4090. The application reports:
CreateSwapChain() error: The selected graphics queue does not support presenting a swapchain image
The result is a black screen and a swapchain error in the game’s log.
Steps to reproduce
-
Boot into KDE Plasma Wayland session.
-
Launch the application via Steam with launch options:
VK_LOADER_DEVICE_ID_FILTER=0x2684 %command%This hides the RTX 5070 from Vulkan entirely, forcing the application onto the RTX 4090.
-
Ensure the window lands on the display output driven by the RTX 4090 (via KDE window rules or in-game
monitor_index). -
Application crashes / black-screens with the swapchain error above.
Verification that the device filter works inside the Steam Runtime
$ /path/to/SteamLinuxRuntime_sniper/_v2-entry-point --verb=waitforexitandrun -- \
env VK_LOADER_DEVICE_ID_FILTER=0x2684 vulkaninfo --summary
GPU0:
deviceType = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
deviceName = NVIDIA GeForce RTX 4090
Only the RTX 4090 is visible to Vulkan, yet swapchain creation still fails.
Expected
vkGetPhysicalDeviceSurfaceSupportKHR should return VK_TRUE for the RTX 4090’s graphics queue when the surface is an Xwayland surface on a display output driven by the same RTX 4090.
Actual
It appears to return VK_FALSE, so the application correctly concludes its graphics queue cannot present and aborts swapchain creation.
Workarounds
- X11 session works: the same
VK_LOADER_DEVICE_ID_FILTER=0x2684setup runs perfectly in a KDE Plasma X11 session — same driver, same loader, same hardware. (However, X11 hits Bug 2 below.) - Gamescope works (
gamescope --prefer-vk-device 10de:2684 -f -- %command%) because gamescope’s WSI layer handles presentation, but in nested Wayland mode this introduces a double-compositing chain (gamescope → kwin → display) that causes visible frame-pacing jitter.
Bug 2 — X11: PRIME output-sink wedges on the second NVIDIA GPU after a Vulkan device-loss event
Symptom
In a KDE Plasma X11 session, the RTX 5070 is the X server primary (NVIDIA-0, Source Output provider) and the RTX 4090 is attached as a PRIME output sink (NVIDIA-G0, Sink Output provider) so the monitor wired to the 4090 can be scanned out.
After a Vulkan application using the 4090 crashes or hits a device-loss event, the PRIME framebuffer-copy pipeline wedges. The 4090’s monitor freezes on the last successfully copied frame and stops receiving updates. Power-cycling the monitor does not help — the DP link comes back up, the monitor immediately re-receives the same stale frame from the wedged scanout, and the OS reports everything as connected and active.
Observed evidence
xrandr --listproviders correctly reports the dual-GPU setup with the 4090 attached as a sink:
Providers: number : 2
Provider 0: id: 0x1b7 cap: 0x1, Source Output ... name:NVIDIA-0 (RTX 5070)
Provider 1: id: 0x378 cap: 0x2, Sink Output ... name:NVIDIA-G0 (RTX 4090)
xrandr --listmonitors correctly reports 3 monitors at the correct positions:
Monitors: 3
0: +*DP-1-0 3840/600x2160/340+3840+0 DP-1-0 (middle, on RTX 4090)
1: +DP-2 3840/600x2160/340+7680+0 DP-2 (right, on RTX 5070)
2: +DP-0 3840/600x2160/340+0+0 DP-0 (left, on RTX 5070)
But nvidia-settings -q CurrentMetaMode only contains outputs from GPU-0 (the 5070):
DPY-3: 3840x2160_120 @3840x2160 +7680+0
DPY-1: 3840x2160_120 @3840x2160 +0+0
Both bugs are in the same general area: the NVIDIA proprietary driver’s handling of the second NVIDIA GPU’s display/presentation pipelines when the X server (or Wayland compositor’s Xwayland) is associated primarily with the first GPU.
- Bug 1 is the WSI-side:
vkGetPhysicalDeviceSurfaceSupportKHRdoesn’t correctly recognize that the second GPU can present to an Xwayland surface whose backing output is on that same GPU. - Bug 2 is the modeset-side: PRIME output-sink scanout from a second NVIDIA GPU is fragile and unrecoverable from RandR after a device-loss event on the sink GPU.
Both effectively force users with multi-NVIDIA-GPU setups to either:
- Use X11 and reboot every time a Vulkan crash takes out the secondary GPU’s display, or
- Use Wayland and use gamescope as a presentation shim with double-compositing overhead, or
- Accept that the second NVIDIA GPU cannot reliably be used for both compute and display in the same session.
Happy to send the nvidia bug log to developer directly but I do not want to post it publicly.