On 7/18/2026 4:22 PM, Alexander Kaplan wrote:
For modes which fit through the link uncompressed only with a 6 bpc
pipe BPP, the link config currently selects 6 bpc with dithering even
if the sink supports DSC.
For HDMI sinks behind a DP to HDMI protocol converter this is the
wrong preference: HDMI knows no 6 bpc transport format, so the
converter has to expand the dithered 6 bpc stream back to 8 bpc for
the HDMI link anyway, and DSC with an at least 8 bpc input provides
a better output quality than that.
Prefer DSC, following the pattern commit ba49a4643cf5 ("drm/i915/dp:
Set min_bpp limit to 30 in HDR mode") uses for HDR: keep the
uncompressed minimum pipe BPP at 8 bpc if the sink supports DSC,
making the uncompressed link config fail for such modes and the mode
fall back to DSC.
As there, if the DSC computation fails, the mode falls back to YCbCr
4:2:0 where supported, or gets rejected.
Besides the output quality, some converters can't even display a
6 bpc stream at high pixel clocks.
Synaptics VMM PCON based DP to HDMI 2.1 adapters from two device
families (branch device IDs SYNAq and SYNAa) output corrupted FRL
timings for an uncompressed RGB 6 bpc 4k120 (1188 MHz) stream,
resulting in a black screen, while the same mode works with DSC
(12 bpc input) and 6 bpc works at lower pixel clocks.
Windows and macOS drive 4k120 on these devices only via DSC.
A lower bpc limit explicitly requested via the max bpc connector
property is still honored.
This keeps the current uAPI behavior (exercised by IGT kms_dither)
and provides an escape hatch for sinks with a broken DSC
implementation.
DP and eDP sinks, and HDMI sinks without DSC support, are not
affected and keep falling back to 6 bpc.
Tested on PTL (xe) with the above PCONs and an LG OLED G4.
Cc: Imre Deak <[email protected]>
Cc: Chaitanya Kumar Borah <[email protected]>
Cc: Ankit Nautiyal <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Signed-off-by: Alexander Kaplan <[email protected]>
---
v2: Apply the limit only to HDMI sinks behind a DFP
(intel_dp_has_hdmi_sink()), leaving DP and eDP link config
policy untouched, and adjust the subject accordingly. (Ankit)
drivers/gpu/drm/i915/display/intel_dp.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index b2464a3dac056..7e860f62d5554 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2671,6 +2671,20 @@ intel_dp_compute_config_limits(struct intel_dp *intel_dp,
crtc_state)));
}
+ /*
+ * HDMI knows no 6 bpc transport format, and DSC with an at least
+ * 8 bpc input provides a better output quality than a dithered
+ * 6 bpc output. Prefer it for HDMI sinks, by failing the
+ * uncompressed link config for modes which would fit only with a
+ * 6 bpc pipe BPP. Honor a lower limit set via the max bpc
+ * connector property.
+ */
+ if (!dsc && intel_dp_has_hdmi_sink(intel_dp) &&
+ intel_dp_supports_dsc(intel_dp, connector, crtc_state) &&
+ limits->pipe.max_bpp >= 24 &&
+ crtc_state->pipe_bpp >= 24)
+ limits->pipe.min_bpp = max(limits->pipe.min_bpp, 24);
Agree with the change.
For HDMI sinks without DSC we keep allowing the dithered 6 bpc
uncompressed config.
For DSC-capable HDMI sinks we skip the 6 bpc uncompressed case and let a
real 8 bpc input be DSC-compressed instead,
giving true 8 bpc at the sink.
A lower max-bpc connector property request is still honored.
LGTM.
Reviewed-by: Ankit Nautiyal <[email protected]>
+
if (limits->pipe.min_bpp <= 0 ||
limits->pipe.min_bpp > limits->pipe.max_bpp) {
drm_dbg_kms(display->drm, "[CONNECTOR:%d:%s] Invalid pipe bpp range:
%d-%d\n",
