VRR fixes, HDMI Gaming Features #4
Open
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
[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. 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 1000 Hz. Use this as the last resort VRRmax. 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] 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. The standards for RB and RBv2 use a fixed 160 or 80 lines for the horizontal blank period. RB v3 can use either 160 or 80. Use this to detect if the current timing mode uses reduced blankinig. It doesn't hurt that the new functions look better and cleaner 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>
KyleGospo
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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://lore.kernel.org/lkml/20260119011146.62302-1-tomasz.pakula.oficjalny@gmail.com/