.../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(-)
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@90-120, 4896x2448@90-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(-) -- 2.51.2
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@90-120, 4896x2448@90-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(-) >
On Thu, 08 Jan 2026, Yaroslav Bolyukin <iam@0la.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@90-120, 4896x2448@90-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
© 2016 - 2026 Red Hat, Inc.