Message-ID: <5b7332c6bc0c7b7f9ba0d95477a5b9f438a07ff6@intel.com>
Date: Fri, 09 Jan 2026 10:15:15 +0200
From: Jani Nikula <jani.nikula@...ux.intel.com>
To: Yaroslav Bolyukin <iam@....ch>, 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>, 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

On Thu, 08 Jan 2026, Yaroslav Bolyukin <iam@....ch> wrote:
> 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?

As I said in [1] I'm hoping to get Ville's approval on the approach, as
he had earlier concerns [2].

BR,
Jani.

[1] https://lore.kernel.org/r/b0b1567707c91806e3758bf0b678c2038dffb3c2@intel.com

[2] https://lore.kernel.org/r/aPF32XpVst5mPVz7@intel.com

>
> 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(-)
>> 

-- 
Jani Nikula, Intel

Powered by blists - more mailing lists