LizardByte / LizardByte/Sunshine

KMS capture: "Couldn't find [/dev/dri/card2]: This shouldn't have happened :/" on multi-GPU (NVIDIA dGPU + AMD iGPU) when only iGPU has an active output

Open
#5,047 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
41.3k
Forks
2.1k
Avg merge
23h 47m
Merged PRs (30d)
124

Description

### Is there an existing issue for this?

- [x] I have searched the existing issues (closest: #4940 and #3778, but both describe a downstream `0x3003` RGB import error on dual-NVIDIA setups — that's a different failure later in the capture pipeline than this)

### Is your issue described in the documentation?

- [x] I have read the documentation

### Is your issue present in the latest beta/pre-release?

Not tested on the latest pre-release. Present on `2025.924.154138` (commit `86188d47a7463b0f73b35de18a628353adeaa20e`) from the Fedora Copr build shipped by Nobara. Code path looks identical in `main`.

### Describe the Bug

On a multi-GPU system (**NVIDIA dGPU on card1, AMD iGPU on card2**), when all outputs on the primary DRM card are disabled and only an active output exists on the secondary card, Sunshine's KMS capture consistently fails with the error:

```
Found monitor for DRM screencasting
Error: Couldn't find ["/dev/dri/card2"]: This shouldn't have happened :/
```

…repeated for every encoder probe (`nvenc`, `vaapi`, `software`), ending in:

```
Fatal: Unable to find display or encoder during startup.
Fatal: Please check that a display is connected and powered on.
```

Wayland output enumeration **does** succeed — Sunshine logs the `wl_output` interface version for the monitor on card2 and even reports `Found monitor for DRM screencasting`. It's the very next step (opening `/dev/dri/card2` for KMS capture) that bails with the internal "This shouldn't have happened" error.

The moment I re-enable any output on card1, Sunshine captures that one fine. Capture on card1 has always worked in my setup. The failure is specific to *capturing from a non-primary DRM card when the primary has no active outputs.*

### Full log excerpt

```
[2026-04-23 20:37:35.870]: Info: /dev/dri/card1 -> nvidia-drm
[2026-04-23 20:37:35.870]: Info: /dev/dri/card2 -> amdgpu
[2026-04-23 20:37:35.870]: Info: Found monitor for DRM screencasting
[2026-04-23 20:37:35.870]: Error: Couldn't find ["/dev/dri/card2"]: This shouldn't have happened :/
[2026-04-23 20:37:36.071]: Info: Screencasting with KMS
[2026-04-23 20:37:36.071]: Info: /dev/dri/card1 -> nvidia-drm
[2026-04-23 20:37:36.071]: Info: /dev/dri/card2 -> amdgpu
[2026-04-23 20:37:36.071]: Info: Found monitor for DRM screencasting
[2026-04-23 20:37:36.071]: Error: Couldn't find ["/dev/dri/card2"]: This shouldn't have happened :/
...
[2026-04-23 20:37:36.676]: Info: Encoder [software] failed
[2026-04-23 20:37:36.676]: Fatal: Unable to find display or encoder during startup.
[2026-04-23 20:37:36.676]: Fatal: Please check that a display is connected and powered on.
```

### Expected Behavior

Sunshine should capture the active monitor on card2 (amdgpu) regardless of whether card1 (nvidia) has any active outputs. At minimum, the \"This shouldn't have happened\" code path should produce an actionable error instead of an internal-state assertion.

### Steps to Reproduce

1. Multi-GPU Linux system: NVIDIA dGPU (card1) + AMD iGPU (card2). KDE Plasma 6 on Wayland.
2. Create a virtual display on card2 via kernel EDID injection (to have something to capture without physical hardware):
- Put a valid 2560×1600 EDID at `/lib/firmware/edid/macbook-virtual.bin`
- Kernel cmdline: `drm.edid_firmware=DP-1:edid/macbook-virtual.bin video=DP-1:e`
3. Boot. Confirm `/sys/class/drm/card2-DP-1/status` = `connected`, `enabled`.
4. `kscreen-doctor output.DP-1.enable output.DP-1.mode.2560x1600@60 output.HDMI-A-3.disable output.DP-5.disable` (disable everything on card1, leave only card2-DP-1 active).
5. Connect a Moonlight client and launch any Sunshine app. Capture fails as above.

Re-enabling any output on card1 (`kscreen-doctor output.HDMI-A-3.enable ...`) makes Sunshine capture it successfully — confirming the failure is about the non-primary DRM card path, not the virtual display itself.

### Additional Context

Use case: trying to use a kernel-injected virtual DP on the iGPU as a headless display target for streaming, so that neither the OLED nor TV physically lights up during MacBook/iPad streaming sessions. The kernel and KDE handle this cleanly — `kscreen-doctor` shows DP-1 as `connected enabled 2560x1600 scale 2.0`, and Sunshine's Wayland enumeration sees it. Only the KMS capture path is blocked.

Possibly related but distinct:
- #4940 — multi-GPU dual NVIDIA, **`0x3003` RGB import error** — that's failing later (during DMA-BUF cross-GPU import). Our error is earlier: Sunshine can't even proceed from \"Found monitor\" to opening the card device.
- #3778 — similar `0x3003`, closed.
- #4971 — prep-cmd timing with virtual displays (fixed, separate issue).

### Host Operating System

Linux

### Operating System Version

Nobara 43 (Fedora 43 base). Kernel `6.19.11-201.nobara.fc43.x86_64`. KDE Plasma 6.6.2, KWin 6.6.2 on Wayland.

### Architecture

amd64/x86_64

### Package

Linux - Fedora Copr

### GPU Type

AMD

### GPU Model

**Multi-GPU:**
- card1 (primary): NVIDIA GeForce RTX 3070 Ti (GA104), PCIe 01:00.0
- card2 (secondary / iGPU): AMD Ryzen 7000 Raphael integrated, PCIe 10:00.0

### GPU Driver/Mesa Version

- NVIDIA: 595.58.03 (open kernel module)
- AMD: Mesa 26.0.4 (amdgpu)

### Capture Method

KMS (Linux)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at Sunshine's KMS capture path after the “Found monitor for DRM screencasting” entry point and trace opening /dev/dri/card2 when card1 has no active outputs. Reproduce with the listed two-GPU Wayland setup and verify that the active card2 monitor captures successfully, or that failures report an actionable error.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp, linux
Domain
desktop, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.