[FROM-ML] drm/amd/display: VRR fixes, HDMI Gaming Features v3 #4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
KyleGospo
changed the title
|
@KyleGospo this is already outdated: https://lists.freedesktop.org/archives/amd-gfx/2026-February/138119.html |
Member
Author
Thanks, I'll update this PR |
|
Seems we need more patches backported to make the newer version work. At least on the upstream 6.18.x series. |
|
Most likely the new series works with 6.19.x series ... |
|
Here are some patches I added so far on top of 6.18.10: AerynOS/recipes@a682588 |
Member
Author
|
@hphilm 6.19 just hit stable so I will update this to the new series |
Member
Author
|
@hphilm Rebased, now v3 and for 6.19.0 |
…_vsdb() [Why] The function would continue to try to parse EDID even if DisplayID extension block wasn't found. Sometimes it got lucky and found AMD vsdb in CEA extension block which made debugging harder. [How] Add a return if DisplayID extension block wasn't found Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] This function started to get very messy and hard to follow. [How] Eject some functionality to separate functions and simplify greatly. Changes in v3: - Less struct traversal in helper functions Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] Some monitors only expose GTF ranges (or others, without Range Limits Only flag). This breaks VRR even though they have explicit FreeSync support. Currently, if monitor ranges were missing, amdgpu only searched for AMD vsdb in DisplayID but many monitors have it in CEA, just like HDMI. [How] For DP and eDP connections, check for VRR ranges provided in AMD vendor- specific data block if VRR range wasn't detected. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3894 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4457 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4747 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4856 Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] Some monitors only expose their full VRR range in AMD vsdb for some reason. [How] Compare exposed ranges and use the bigger one. This check could be merged with the previous one but it's better to keep them separate to easily convey their meaning. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4177 Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] DP->HDMI PCONs prevously entered the DP path [How] Restructure amdgpu_dm_update_freesync_caps() and move dm_get_adaptive_sync_support_type() to dm_helpers_is_vrr_pcon_allowed() to better reflect what this function does. It never actually gave us any other info. Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] It's currently very hard to test if a random PCON supports VRR and report it's ID. [How] Adds override as part of dc debug mask. Allows faster testing and reporting of VRR-compatible DP->HDMI adapters. Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] Chrontel CH7218 found in Ugreen DP -> HDMI 2.1 adapter (model 85564) works perfectly with VRR after testing. VRR and FreeSync compatibility is explicitly advertised as a feature so it's addition is a formality. Support FreeSync info packet passthrough and "generic" HDMI VRR. [How] Add CH7218's ID to dm_helpers_is_vrr_pcon_allowed() Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4773 Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] Drivers may need info about gaming features exposed by HDMI sinks. Add a central way of storing this information. [How] Adds flags and a struct to hold HDMI VRR information. `supported` here is an additional property which allows easier parsing in consumers and adds a bit of logic used to detect malformed VRRmin/VRRmax values. Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> Tested-by: Bernhard Berger <bernhard.berger@gmail.com>
[Why] PCONs support sending out HDMI VRR infopackets on their own and this makes this types not specific to FreeSync [How] Make the name more generic for the upcoming HDMI VRR over PCON implementation Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> Tested-by: Bernhard Berger <bernhard.berger@gmail.com>
[Why] Not all TVs support FreeSync and many TVs suffer from VRR flickering while Freesync is activated. [How] This works the same as FreeSync over PCON just without sending FreeSync info packets (we're sending standard DisplayPort info packets) + reading the VRR range from the HDMI Forum vendor specific data block. PCONs take over HDMI VRR triggering. Prefer HDMI VRR over FreeSync to reduce VRR flickering on many TVs. FreeSync over HDMI seems to be a fallback solution and not a first-class citizen. This especially helps VMM7100. Tested with VMM7100 and CH7218 based adapters on multiple HDMI 2.1 and HDMI 2.0 devices. (Samsung S95B, LG C4, Sony Bravia 8, Dell AW3423DWF) Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4805 Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> Tested-by: Bernhard Berger <bernhard.berger@gmail.com>
[Why] VRRmax=0 is a valid value and means that the upper bound is guared by the selected video mode. [How] In this context, saved vrr max is the max possible refresh rate ever. Try getting upper VRR bound from AMD vsdbif it exists or rely on the limitations of BRR in VTEM info frames. I found through testing, that TVs seem to reject VTEM when BRR is set to over 1023 Hz. Use this as the last resort VRRmax. 1023 is the max value for a 10-bit field as well. v2: - Update max BRR value to 1023 Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] HDMI vsif was assigned to vsp_infopacket (FreeSync) field [How] Build HDMI vsif in the correct hfvsif_infopacket field Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] We need info about these features in parts of the driver where fishing for drm_connector struct is infeasible. [How] Add three new fields to dc_edid_caps and fill them if connected device is HDMI based on it's EDID Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] Support for triggering ALLM in modern TVs is missing. When HDMI vsif was added in 2019: commit 3c2381b ("drm/amd/display: add support for VSIP info packet") it was improperly handeled as HDMI actually has two separate vsifs. The implementation was based on H14b-vsif and ALLM bit was messing it up because H14b-vsif doesn't support ALLM. It was later removed in: commit 75f77aa ("drm/amd/display: Send H14b-VSIF specified in HDMI") ALLM is supported by hf-vsif (HDMI Forum) instead. [How] Add proper logic to construct either h14b-vsif or hf-vsif based on required capabilities. Currently, only ALLM from hf-vsif is supported. Turns out, hf-vsif is almost identical to h14b-vsif, BUT has additional two bytes of data after OUI. First byte is static and seems like a version supported by leftover define. Second byte consists of 3D and ALLM bits. Implement logic to offset 3D data if building hf-vsif. Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] ALLM automatically puts TVs into low latency modes (gaming modes) which we basically always want for PC use, be it gaming, or using precise inputs like mice and keyboards. [How] Read the ALLM info from HDMI caps and use it to determine if ALLM should be indicated in HDMI Forum vsif. Additionally, make sure VIC modes are translated in case of ALLM active as VIC cannot be used in conjunction with hf-vsif. I learned this the hard way... Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] Some users prefer to always manually control ALLM/Gaming mode while others might want it permanently forced on. [How] Since there isn't yet an API to control this, expose module parameter Changes in v3: - Include a fix for possible NULL pointer dereference by Peter Closes: CachyOS/linux-cachyos#680 Co-developed-by: Peter Jung <admin@ptr1337.dev> Signed-off-by: Peter Jung <admin@ptr1337.dev> Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] VTEM info fram building was removed back in: commit a9f54ce ("drm/amd/display: Refactoring VTEM"), but it's needed to support HDMI VRR signalling. [How] Build completely new and more robust functions to build out the VTEM infopacket. Many values are defined but could have added logic in the future, that's shy they are not static values but already value + bit position in it's byte. Reduced blanking detection was previously missing. Use possible hblank periods defined for RB1 (from CVT 1.2), RB2 and RB3 (from CVT 2.1). Changes in v3: - Use div_u64() instead of division operator Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] We'd like to expose VRR functionality to end user if HDMI sink is advertising it's support. [How] VTEM info frame is used to signal HDMI sink that VRR is active. Use VTEM info packet as vrr_infopacket Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
[Why] Many TVs and other HDMI sinks suffer from blanking and possibly other glitches when VRR is toggled. With FreeSync present on such sinks, they behave like the signal is always variable, even in fixed refresh rate situations. [How] Keep HDMI VRR toggled if it's supported and not explicitly disabled. Additionnally, add module parameter which allows users to configure HDMI VRR triggering to only happen when the signal is truly asking for variable state. This is useful if end user has a TV that automatically toggles ALLM/Game mode when VRR is active and such user doesn't want gaming mode in normal desktop usage. Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
KyleGospo
changed the title
Member
Author
|
@pastaq should be up to standard now |
KyleGospo
changed the title
pastaq
approved these changes
Feb 13, 2026
|
LGTM |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://lists.freedesktop.org/archives/amd-gfx/2026-February/138119.html