From: teapot <huangalex409@gmail.com>
To: "Ata İlhan Köktürk" <atailhan2006@gmail.com>,
amd-gfx@lists.freedesktop.org
Cc: "Harry Wentland" <harry.wentland@amd.com>,
"Leo Li" <sunpeng.li@amd.com>,
"Rodrigo Siqueira" <siqueira@igalia.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [DRM] amdgpu: HDMI FreeSync not exposed on Samsung S22C31x despite AMD VSDB
Date: Wed, 23 Sep 2026 12:07:26 -0400 [thread overview]
Message-ID: <696580d8-cf2e-47aa-8616-7d930c2f5b82@gmail.com> (raw)
In-Reply-To: <20260923002718.5915-1-atailhan2006@gmail.com>
On 2026-09-22 20:27, Ata İlhan Köktürk wrote:
> Hi,
>
> I am investigating an issue where HDMI FreeSync
> is not exposed for a Samsung S22C31x monitor on
> an AMD Picasso/Raven 2 GPU, although the monitor
> advertises an AMD FreeSync range in its EDID and
> VRR works under Windows.
>
> Hardware/software:
>
> * GPU: 03:00.0 VGA compatible controller [0300]:
> Advanced Micro Devices, Inc. [AMD/ATI] Picasso/Raven 2
> [Radeon Vega Series / Radeon Vega Mobile Series]
> [1002:15d8] (rev c2)
> * Kernel: 7.2.5-200.fc44
> * Compositor: Sway (Wayland)
> * Monitor: Samsung S22C31x
> * Connector: HDMI-A-1
> * EDID serial: H9DX100210
> * Kernel command line includes: amdgpu.freesync_video=1
>
> Observed:
>
> * swaymsg -t get_outputs reports "Adaptive sync: disabled" for HDMI-A-1.
> * Adaptive sync remains disabled at both 1920x1080@60 Hz and 1920x1080@75 Hz.
> * The same monitor exposes and enables FreeSync under Windows.
>
> The EDID contains the following AMD Vendor-Specific Data Block:
>
> Vendor-Specific Data Block (AMD), OUI 00-00-1A:
> Version: 1
> Feature Caps: 0x01
> Minimum Refresh Rate: 48 Hz
> Maximum Refresh Rate: 75 Hz
> Flags 1.x: 0x00>
> The HDMI VSDB therefore appears to advertise a 48-75 Hz FreeSync range.
>
> There is also this message in dmesg:
>
> amdgpu 0000:03:00.0: [drm] Failed to setup vendor infoframe on connector HDMI-A-1: -22
>
> I believe this is the -EINVAL path from
> drm_hdmi_vendor_infoframe_from_display_mode() for this timing and
> is probably unrelated to the FreeSync issue.
>
> The part I am currently investigating is amdgpu_dm_update_freesync_caps().
>
> For HDMI, the driver calls parse_hdmi_amd_vsdb(), which
> on this DCN configuration goes through the DMUB path:
>
> parse_hdmi_amd_vsdb()
> -> parse_edid_cea()
> -> parse_edid_cea_dmub()
> -> dm_edid_parser_send_cea()
> -> output->amd_vsdb.freesync_supported
>
> If the DMUB parser returns freesync_supported == 0,
> the driver does not expose the connector as VRR capable.
>
> What makes this interesting is that the DRM EDID parser also
> contains the corresponding AMD VSDB information in
> connector->display_info.amd_vsdb, while the DMUB result
> does not result in FreeSync being exposed.
>
> I am wondering about the following:
>
> 1. Is the AMD VSDB layout above expected to be accepted by
> the DMUB EDID parser, particularly with
> Feature Caps 0x01, Flags 1.x == 0x00, and no MCCS VCP code byte?
AFAIK the driver will consider HDMI FreeSync unavailable if MCCS VCP
code is 0x0. HDMI FreeSync needs this VCP code.>
> 2. If the DMUB parser rejects this form of AMD VSDB, should amdgpu_dm
> fall back to the software-parsed connector->display_info.amd_vsdb
> when determining FreeSync capability?
The amd_vsdb struct is currently only for the V2+ luminosity fields, and
don't affect FreeSync detection. I had added FreeSync fields support and
those changes are in drm-next, but haven't made it up to the Torvalds
tree yet.
>
> I have a working kernel tree and can run diagnostic tests
> or test a small patch. I can also provide drm.debug
> output or DMUB-related traces if useful.
I think this might be a case where the Windows FreeSync detection has
diverged from the Linux detection, maybe Harry would be able to provide
more insight on this?
The monitor's EDID would probably be useful too, I'm not quite sure how
to make sense of the edid-decode output since there's a few guessed
fields in the AMD VSDB block and hasn't been updated since 2024.>
> Thanks,
> Ata İlhan Köktürk
Best,
Alex
next prev parent reply other threads:[~2026-09-23 16:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 0:27 Ata İlhan Köktürk
2026-09-23 16:07 ` teapot [this message]
2026-09-23 19:45 ` Zuo, Jerry
2026-09-24 17:12 ` Ata İlhan Köktürk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=696580d8-cf2e-47aa-8616-7d930c2f5b82@gmail.com \
--to=huangalex409@gmail.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=atailhan2006@gmail.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=siqueira@igalia.com \
--cc=sunpeng.li@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®