Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
The migration is almost done, at least the rest should happen in the background. There are still a few technical difference between the old cluster and the new ones, and they are summarized in this issue. Please pay attention to the TL:DR at the end of the comment.
@drago01 Just to confirm, when you validate DP1.4 VRR is working, are you using another DP1.4 VRR capable monitor, or using the Samsung DP2.1 monitor by forcing it light up at DP1.4 link rate ?
I am also seeing this issue on the same type of Samsung Odyssey G9 monitor with DisplayPort 2.1. I'm including some relevant logging from amd-staging-drm-next built from agd5f/linux@7be9027d of both the monitor's DisplayPort 1.4 VRR enabled edid-decode and drm_info as well as the DisplayPort 2.1 VRR missing edid-decode and drm_info in case it's helpful, along with a dmesg after toggling between monitor modes and DisplayPort revisions.
There is no vrr_capable property attached for DP2.1 in the drm_info dump, which suggests this function (drm_connector_attach_vrr_capable_property) isn't called at all.
Both EDIDs should let VRR work (in your case max_vfreq - min_vfreq > 10, source).
Maybe you could hack the code so that the MST root check isn't there or simply register the property somewhere else and see if it gets set to 1 later?
Since I am still in the middle of other tasks, please help to add below debug code, and let me know the debug print. (Need to add drm.debug=0x106 into grub). Thanks a lot.
@jzuo I did my best to manually rebase that onto amd-staging-drm-next since some of your diffs weren't lining up for me, and I'm only seeing one of those debugging logs in my dmesg so maybe I messed up: