On my MSI MAG 271QPX32 (320Hz QD-OLED over DP 1.4, RX 9070 XT), 320Hz looks like a 720p image stretched to fill the screen whenever Adaptive-Sync is on in the monitor's OSD. Custom modes at 305-315Hz put it into its self-test pattern instead. Windows is fine on the same machine and cable. It's the same bug as https://gitlab.freedesktop.org/drm/amd/-/issues/5988, where an LG at 280Hz shows up as 24Hz.
The cause is the v1 FreeSync infopacket, which native DP sinks get unless they're a whitelisted PCON or support Replay. It stores the min and max refresh in one byte each, so 320 wraps to 64. Patch 1 caps those bytes at 255 instead of letting them wrap. With the EDID range capped at 255, the monitor gets the same bytes patch 1 sends, and the picture was correct, so I tagged it for stable. Patch 2 sends the v3 packet to sinks that advertise AMD VSDB v3 and go above 255Hz, so VRR gets the full range. Sinks at 255Hz and below are unchanged. This builds on what sunryze and oystersuki worked out in that issue. sunryze found that the VSDB version was only saved for Replay sinks on DP and tested sending v3 on their LG. oystersuki suggested pairing that with a 255 cap for sinks that don't advertise v3. Neither has a public email, so they're credited here instead of with tags. Tested with the series backported to 7.2.13: 320Hz looks right, and with VRR on, the monitor's refresh readout follows frame caps at 300, 270, 240, and 100fps. Both patches add KUnit tests. Cooper Morgan (2): drm/amd/display: Saturate refresh rates in v1/v2 FreeSync infopackets drm/amd/display: Use FreeSync v3 infopacket for sinks above 255 Hz .../display/amdgpu_dm/amdgpu_dm_connector.c | 2 +- .../display/amdgpu_dm/amdgpu_dm_freesync.c | 7 ++ .../tests/amdgpu_dm_connector_test.c | 25 ++++ .../amdgpu_dm/tests/amdgpu_dm_freesync_test.c | 116 ++++++++++++++++++ .../amd/display/modules/freesync/freesync.c | 12 +- 5 files changed, 158 insertions(+), 4 deletions(-) -- 2.56.0
