Linux virtual display via forced DRM connector + custom EDID (client-adaptive resolution)

[EnriqueWood]

Problem:

On Linux, Apollo has no virtual display yet (SudoVDA is Windows-only, and the README lists Linux support as planned). So a Linux host has to
either stream a real monitor at its fixed resolution, or use a hardware dummy dongle, which is limited to whatever modes the dongle's EDID
advertises and caps link bandwidth. There's no per-client native resolution like the Windows experience.

Proposed behavior:

A virtual display on Linux that isn't tied to a physical monitor and takes the client's requested resolution and refresh rate, matching what
Apollo already does on Windows. Capture is already solved on Wayland (portal/pipewire path), so the missing piece is providing the virtual
output and driving its mode per client.

Affected area:

Linux host only: display/output management and the virtual-display subsystem. Windows is unaffected.

Existing related work:

• Issue #1161 (Virtual Display does not work on Linux): the symptom and the demand.
• Discussion #107 (Linux port?): the maintainer noted Linux virtual display "won't be that soon" and that X11 and Wayland differ here.
• MrOz59/Apollo-Linux: a community fork that does Linux virtual display via EVDI (a kernel module). It's a real virtual display, supports
  live mode changes, and is the closest match to the SudoVDA model. Listed here as prior art and one viable path, not as a "just merge it"
  suggestion.
• My POC (link below): a different, compositor-agnostic path that needs no extra kernel module.

Technical notes (limitations, risks, compatibility)

How the POC works:

• Force-enable a spare DRM connector with a generated EDID, via the kernel cmdline video=:e drm.edid_firmware=:edid/.bin.
  One gotcha: on the NVIDIA proprietary driver drm.edid_firmware alone is silently ignored, you also need video=:e. With both, you get a fully
  virtual output, no dongle and no HBR bandwidth cap.
• The EDID is generated from a mode list so the client gets an exact match. On connect, a prep step sets the virtual output to the client's
  mode (or the closest one) and makes it the only active display; if a client asks for a mode that isn't there, it's queued and the EDID is
  regenerated.

Limitations, and why EVDI or a real in-tree virtual device is probably the better long-term answer:

• The firmware EDID is read at boot and NVIDIA won't hot-reload it, so a newly-added mode only appears after a reboot. EVDI or a real virtual
  DRM device can change modes live, which fits Apollo's per-client model better. The DRM-connector approach is really a no-extra-module
  fallback.
• On a forced virtual connector the NVIDIA driver won't expose HDR or VRR (it only does that over a real HDMI 2.1 link with SCDC), so HDR
  still needs a real display.

Tested on: Nobara (Fedora 43 base), kernel 7.0.x, KDE Plasma 6 Wayland (KWin), NVIDIA RTX 3090 (proprietary driver 595.71.05), with a client on a phone.

POC + scripts + notes: https://github.com/EnriqueWood/sunshine-virtual-displays-support-poc

Why this matters

It brings Apollo's signature per-client native-resolution experience to Linux without dongles, builds directly on capture that already works,
and covers the headless and "use the PC normally while someone streams to it" cases. Linux support is already on the roadmap, so this is
meant as a concrete data point plus working code to help it along.

I'm not a graphics or kernel developer (I built the POC with a lot of help from an AI assistant), so this is a feature request rather than a
PR. I'm glad to share the scripts, EDID generator, and logs, or to test patches, and happy to take direction on the EVDI vs DRM-connector
question.

[ClassicOldSong]

🙈 once again...

#589 (comment)

There's already a PR for a much better approach but that still requires more testing.