Message-ID: <5d1fc27a-eea0-4995-8b8e-46006144ae7b@0la.ch>
Date: Thu, 8 Jan 2026 21:45:15 +0100
From: Yaroslav Bolyukin <iam@....ch>
To: Yaroslav Bolyukin <iam@...h.pw>,
 Ville Syrjälä <ville.syrjala@...ux.intel.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Jani Nikula <jani.nikula@...ux.intel.com>, Wayne Lin <Wayne.Lin@....com>,
 Harry Wentland <harry.wentland@....com>,
 Alex Deucher <alexander.deucher@....com>
Cc: Leo Li <sunpeng.li@....com>, Rodrigo Siqueira <siqueira@...lia.com>,
 Christian König <christian.koenig@....com>,
 Wayne Lin <Wayne.Lin@....com>, amd-gfx@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v7 0/7] VESA DisplayID fixed DSC BPP value support

Hi,

Now that every patch in this patchset has a review, any chance this can 
be picked up for drm-misc-next?

Or should it go through amd-staging-drm-next, given that the main EDID 
change is only handled for amdgpu driver right now?

Best regards,
Lach

On 2025-12-02 12:02, Yaroslav Bolyukin wrote:
> VESA DisplayID spec allows the device to force its DSC bits per pixel
> value.
> 
> For example, the HTC Vive Pro 2 VR headset uses this value in
> high-resolution modes (3680x1836@...120, 4896x2448@...120), and when the
> kernel doesn't respect this parameter, garbage is displayed on the HMD
> instead.
> 
> Me and other users have successfully tested the old (v3) version of this
> patch (which was applying DSC BPP value unconditionally, thus incorrect:
> https://lkml.org/lkml/2023/2/26/116) on Vive Pro 2 and
> Bigscreen Beyond VR headsets, and have been using it daily, it is known
> to work and doesn't seem to break anything else since 2022.
> 
> Previously, I didn't have enough dedication to get it merged, I hope
> this time I will manage to get it to v6.19 :D
> 
> Regarding driver support - I have looked at amdgpu and Nvidia's
> open-gpu-kernel-modules, and both seem to have some indication for this
> value; however, in Linux, it is unused in both.
> 
> First patch implements parsing of DSC BPP values and display mode VII
> timings flag which mandates that the DSC BPP value should actually be
> used for this display mode.
> 
> The second patch implements handling of this value for AMDGPU driver.
> 
> The only thing that I don't like in the current implementation, is how
> the value of `dsc_passthrough_timings_support` flag is propagated from
> the connector display modes to the mode created in `DRM_IOCTL_MODE_SETCRTC`
> handler (which is used for VR display initialization in Monado and
> StreamVR), it feels like this flag should be initialized by the kernel
> itself, but as far as I can see there is no correct way to do this, as
> the timing constraints calculation belongs to the individual drivers.
> 
> Another problem with how this flag is set, is that there is no hard
> connection between modes creaded in `SETCRTC` and the modes actually
> defined by connector, so the current implementation searches for the
> resolution and refresh rate that match exactly declared to obtain
> this flag value. This might not be correct, as device might not support
> the other mode at all, but the situation won't be any worse for the
> existing devices, as the currently they don't work at all, and there
> is no other known devices on the market to check their assumption in
> regard to this part of specs, and the spec does not describe how that
> should work.
> 
> Both of those downsides are due to the fact my understanding of DRM
> subsystem is not that high. If another implementation would be proposed
> by AMDGPU maintainers - I will gladly implement it here.
> 
> v6->v7:
>   * Print DSC bpp value in fixed point format instead of x16
>   * MSO should only be enabled for eDP, not the other way round.
> v5->v6:
>   * amdgpu: only apply dsc bpp to modes that match exactly the declared
>     modes with this flag set.
> v4->v5:
>   * The patch was split into multiple
>   * Disabled MSO parsing for eDP displays
>   * Disabled MSO logs if not used
>   * Minor codestyle changes: lines moved around, naming, passing of
>     function arguments
> v3->v4:
>   * This patch now parses timings support flag on type VII block, instead
>     of applying it unconditionally. Previously I didn't understand the
>     spec properly.
>   * Now it also is not being applied for non-supported and/or non-VII
>     blocks in amdgpu driver.
> 
> Regards,
> 
> Lach
> 
> Yaroslav Bolyukin (7):
>    drm/edid: rename VESA block parsing functions to more generic name
>    drm/edid: prepare for VESA vendor-specific data block extension
>    drm/edid: MSO should only be used for non-eDP displays
>    drm/edid: parse DSC DPP passthru support flag for mode VII timings
>    drm/edid: for consistency, use mask everywhere for block rev parsing
>    drm/edid: parse DRM VESA dsc bpp target
>    drm/amd: use fixed dsc bits-per-pixel from edid
> 
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  16 +++
>   drivers/gpu/drm/drm_displayid_internal.h      |  11 ++
>   drivers/gpu/drm/drm_edid.c                    | 102 +++++++++++-------
>   include/drm/drm_connector.h                   |   6 ++
>   include/drm/drm_modes.h                       |  10 ++
>   5 files changed, 109 insertions(+), 36 deletions(-)
> 

Powered by blists - more mailing lists