Skip to content

dp: scope virtual sink caps to forced connectors#1196

Open
Rohithmatham12 wants to merge 1 commit into
NVIDIA:mainfrom
Rohithmatham12:dp-virtual-sink-caps
Open

dp: scope virtual sink caps to forced connectors#1196
Rohithmatham12 wants to merge 1 commit into
NVIDIA:mainfrom
Rohithmatham12:dp-virtual-sink-caps

Conversation

@Rohithmatham12

@Rohithmatham12 Rohithmatham12 commented Jun 11, 2026

Copy link
Copy Markdown

Summary

  • Add a DP-library-visible virtual sink DPCD fallback flag.
  • Set that flag only when NVKMS handles a force-connected DPLib connector that has no plugged DP device.
  • Use synthesized DPCD/DSC/FEC/HDR capabilities only while that virtual-sink fallback flag is set.
  • Leave ordinary failed DPCD reads on physical DP sinks on the existing error path.

This is a scoped variant of the DP headless/virtual-display approach discussed in #1195. The goal is to support force-enabled DP connectors with EDID overrides for headless Sunshine/Moonlight-style streaming, while keeping the fake capability path limited to the explicit force-connected virtual sink case.

Why

PR #1195 reports successful hardware validation for a force-enabled DP connector with no physical sink, but its current implementation falls back to fake DPCD caps on any failed caps read. That fixes the headless case, but it may be broader than necessary for physical DP sinks with transient AUX failures.

This version threads an explicit virtual-sink fallback state from the pRequest->forceConnected + unplugged DPLib path into the DP library, and gates the fake DPCD/DSC/FEC/VSC colorimetry behavior on that state.

Testing

  • git diff --check
  • make -C kernel-open -n modules
    • Reached the kernel build handoff and then stopped in this macOS workspace because /lib/modules/25.5.0/build is not present.

Reporter validation from #1196 / #1195 discussion:

  • Hardware/software: RTX 3060 Ti, driver 610.43.02, kernel 7.0.11, KDE Wayland.
  • Setup: branch stacked on modeset: honor forced FRL rate during link assessment #1186, DP-2 force-enabled via drm.edid_firmware=DP-2:edid/ video=DP-2:e with a 4K120 EDID.
  • Result: DP-2 offers and sets 3840x2160@119.88.
  • HDR and WCG both enable on the forced DP connector.
  • Logs report DSC Mode = SINGLE and the modeset sticks.
  • Regression check: a real DP monitor plugged into the same GPU on DP-3 remains HDR incapable with no 4K120 offered, confirming the physical sink path is left alone in this setup.
  • Cold-boot check: simulated long pulse sets cleanly; no SOR assignment or connectorActive issue was observed.

Related to #1195 and #1184.

@Rohithmatham12

Copy link
Copy Markdown
Author

@HarryAnkers I opened this as a narrower variant of the DP virtual-sink approach from #1195.

The main difference is scoping: instead of using fake DPCD/DSC/FEC/HDR capabilities for any failed DPCD caps read, this only enables them when NVKMS is handling a force-connected DPLib connector with no plugged DP device. The goal is to preserve the 4K120/HDR headless DP behavior you validated, while keeping normal physical DP sink behavior on the existing path.

If you can test this branch on the same setup, the key checks would be whether 3840x2160@120 appears/sets, HDR enables, and your physical DP monitor regression check still behaves normally.

@HarryAnkers

Copy link
Copy Markdown

Gave this a test on my headless setup (RTX 3060 Ti, 610.43.02, kernel 7.0.11, KDE Wayland), stacked on top of #1186, with DP-2 force-enabled via drm.edid_firmware=DP-2:edid/<file> video=DP-2:e and a 4K120 EDID.

Happy to say it works, same result I got from #1195 but with your tighter scoping:

  • DP-2 offers and actually sets 3840x2160@119.88, HDR and WCG both enable, and I get DSC Mode = SINGLE in the log. The modeset sticks fine.
  • The virtual sink flag does its job. I plugged a real DP monitor into the same GPU (DP-3) and it stays HDR: incapable with no 4K120 offered, so the real sink path is left alone. That was the main worry on mine, so this is the better approach.
  • Didn't hit any SOR assignment or connectorActive trouble in practice. The simulated long pulse sets cleanly from a cold boot.

I'm glad to close #1195 in favour of this one, your version is the right shape for review. Thanks for tightening it up.

@Rohithmatham12

Copy link
Copy Markdown
Author

@HarryAnkers thanks for testing this on the same setup and for checking the physical DP monitor path too. I updated the PR description with your validation details.

The key result for review is that the force-enabled DP virtual sink path gets 3840x2160@119.88, HDR/WCG, and DSC Mode = SINGLE, while the real DP monitor on DP-3 stays on the normal physical-sink behavior. That was the intended scoping difference from #1195.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants