VESA vendor header from DisplayID spec may contain fixed bit per pixel
rate, it should be respected by drm driver
Signed-off-by: Yaroslav Bolyukin <iam@lach.pw>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 0d03e324d5b9..ebe5bb4eecf8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6521,6 +6521,11 @@ static void fill_stream_properties_from_drm_display_mode(
stream->output_color_space = get_output_color_space(timing_out, connector_state);
stream->content_type = get_output_content_type(connector_state);
+
+ /* DisplayID Type VII pass-through timings. */
+ if (mode_in->dsc_passthrough_timings_support && info->dp_dsc_bpp != 0) {
+ stream->timing.dsc_fixed_bits_per_pixel_x16 = info->dp_dsc_bpp;
+ }
}
static void fill_audio_info(struct audio_info *audio_info,
@@ -7067,6 +7072,13 @@ create_stream_for_sink(struct drm_connector *connector,
&mode, preferred_mode, scale);
preferred_refresh = drm_mode_vrefresh(preferred_mode);
+
+ /*
+ * HACK: In case of multiple supported modes, we should look at the matching mode to decide this flag.
+ * But what is matching mode, how should it be decided?
+ * Assuming that only preferred mode would have this flag.
+ */
+ mode.dsc_passthrough_timings_support = preferred_mode->dsc_passthrough_timings_support;
}
}
@@ -7756,7 +7768,7 @@ create_validate_stream_for_sink(struct drm_connector *connector,
drm_dbg_kms(connector->dev, "%s:%d Validation failed with %d, retrying w/ YUV420\n",
__func__, __LINE__, dc_result);
aconnector->force_yuv420_output = true;
- }
+}
stream = create_validate_stream_for_sink(connector, drm_mode,
dm_state, old_stream);
aconnector->force_yuv422_output = false;
--
2.51.0
On Thu, 16 Oct 2025, Yaroslav Bolyukin <iam@lach.pw> wrote:
> VESA vendor header from DisplayID spec may contain fixed bit per pixel
> rate, it should be respected by drm driver
>
> Signed-off-by: Yaroslav Bolyukin <iam@lach.pw>
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 0d03e324d5b9..ebe5bb4eecf8 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6521,6 +6521,11 @@ static void fill_stream_properties_from_drm_display_mode(
>
> stream->output_color_space = get_output_color_space(timing_out, connector_state);
> stream->content_type = get_output_content_type(connector_state);
> +
> + /* DisplayID Type VII pass-through timings. */
> + if (mode_in->dsc_passthrough_timings_support && info->dp_dsc_bpp != 0) {
> + stream->timing.dsc_fixed_bits_per_pixel_x16 = info->dp_dsc_bpp;
> + }
If we had mode->dp_dsc_bpp_x16 directly, or something better named, this
would be simpler. This will eventually be replicated in a bunch of
drivers.
BR,
Jani.
> }
>
> static void fill_audio_info(struct audio_info *audio_info,
> @@ -7067,6 +7072,13 @@ create_stream_for_sink(struct drm_connector *connector,
> &mode, preferred_mode, scale);
>
> preferred_refresh = drm_mode_vrefresh(preferred_mode);
> +
> + /*
> + * HACK: In case of multiple supported modes, we should look at the matching mode to decide this flag.
> + * But what is matching mode, how should it be decided?
> + * Assuming that only preferred mode would have this flag.
> + */
> + mode.dsc_passthrough_timings_support = preferred_mode->dsc_passthrough_timings_support;
> }
> }
>
> @@ -7756,7 +7768,7 @@ create_validate_stream_for_sink(struct drm_connector *connector,
> drm_dbg_kms(connector->dev, "%s:%d Validation failed with %d, retrying w/ YUV420\n",
> __func__, __LINE__, dc_result);
> aconnector->force_yuv420_output = true;
> - }
> +}
> stream = create_validate_stream_for_sink(connector, drm_mode,
> dm_state, old_stream);
> aconnector->force_yuv422_output = false;
--
Jani Nikula, Intel
On 2025-10-16 18:39, Jani Nikula wrote:
> On Thu, 16 Oct 2025, Yaroslav Bolyukin <iam@lach.pw> wrote:
>> VESA vendor header from DisplayID spec may contain fixed bit per pixel
>> rate, it should be respected by drm driver
>>
>> Signed-off-by: Yaroslav Bolyukin <iam@lach.pw>
>> ---
>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++++++++++++-
>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 0d03e324d5b9..ebe5bb4eecf8 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -6521,6 +6521,11 @@ static void fill_stream_properties_from_drm_display_mode(
>>
>> stream->output_color_space = get_output_color_space(timing_out, connector_state);
>> stream->content_type = get_output_content_type(connector_state);
>> +
>> + /* DisplayID Type VII pass-through timings. */
>> + if (mode_in->dsc_passthrough_timings_support && info->dp_dsc_bpp != 0) {
>> + stream->timing.dsc_fixed_bits_per_pixel_x16 = info->dp_dsc_bpp;
>> + }
>
> If we had mode->dp_dsc_bpp_x16 directly, or something better named, this
> would be simpler. This will eventually be replicated in a bunch of
> drivers.
>
> BR,
> Jani.
Unfortunately, that won't solve the problem that there is no good way to
pass this value from display_modes created from e.g
DRM_IOCTL_MODE_SETCRTC. I believe it would be better if there was a
syscall to inherit from a native mode instead of creating a new one, but
this is too far fetched.
I'll check how this was implemented by nvidia open driver, as they have
added support for this value in their driver somehow.
>> }
>>
>> static void fill_audio_info(struct audio_info *audio_info,
>> @@ -7067,6 +7072,13 @@ create_stream_for_sink(struct drm_connector *connector,
>> &mode, preferred_mode, scale);
>>
>> preferred_refresh = drm_mode_vrefresh(preferred_mode);
>> +
>> + /*
>> + * HACK: In case of multiple supported modes, we should look at the matching mode to decide this flag.
>> + * But what is matching mode, how should it be decided?
>> + * Assuming that only preferred mode would have this flag.
>> + */
>> + mode.dsc_passthrough_timings_support = preferred_mode->dsc_passthrough_timings_support;
>> }
>> }
>>
>> @@ -7756,7 +7768,7 @@ create_validate_stream_for_sink(struct drm_connector *connector,
>> drm_dbg_kms(connector->dev, "%s:%d Validation failed with %d, retrying w/ YUV420\n",
>> __func__, __LINE__, dc_result);
>> aconnector->force_yuv420_output = true;
>> - }
>> +}>> stream = create_validate_stream_for_sink(connector, drm_mode,
>> dm_state, old_stream);
>> aconnector->force_yuv422_output = false;
>
Regards,
Lach
© 2016 - 2025 Red Hat, Inc.