On Wed, Jun 10, 2026 at 07:44:11PM +0200, 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.
> DSC with an at least 8 bpc input provides a better output quality
> than a dithered 6 bpc output, so prefer it, 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 sinks 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.
> Sinks without DSC support 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]>
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 85d3aa3b9894..13cfccf60490 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2839,6 +2839,18 @@ intel_dp_compute_config_limits(struct intel_dp
> *intel_dp,
>
> crtc_state)));
> }
>
> + /*
> + * Prefer DSC with an at least 8 bpc input over a dithered 6 bpc
> + * uncompressed output, 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_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);
So, this would be a generalization for/instead of the HDR logic above
using a intel_dp_in_hdr_mode() ? 30 : 24 limit (which would also apply a
lower max-bpc limit for HDR as well).
Agree that DSC vs. dithering would probably produce a better image.
There could be other reasons to prefer DSC, like a more finegrained BW
allocation on MST links. But there are also reasons to prefer non-DSC
mode like power saving (no need to enable either a DSC encoder in the
source or a DSC decoder downstream), or reliability issues related to
DSC.
There's been a lot of talk internally about the above aspects and how to
handle them in a way suitable in all scenarios. Hence, I'm not sure if
adding more policies to the driver like the above bpp limit/DSC
preference is too ad-hoc/early or not at this point. At some point we
will need a better logic for sure to decide between DSC or non-DSC, but
that could be based on userspace tunable knobs for instance. Maybe
someone else could also weigh in on this.
> +
> 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",
> --
> 2.54.0
>
>
