I just found out that my LG 27GL850 monitor shows up as “FreeSync: not supported” on win11 and latest drivers. The monitor itself, as well as LG’s OSC happily proclaims FreeSync is active. This is no matter how I connect the monitor, which makes sense as every connector on the framework is an usb-c-to-x adapter.
This also means that even connecting it via the HDMI adapter card results in it being displayed as unsupported, even though if I connect it via HDMI to my old 2500U based laptop, the option gets enabled.
I don’t quite get it. The monitor is listed as supported at AMD’s freesync site (page 3 if you filter by manufacturer → LG). Also, LG says DP connection is always prefered.
I have tried looking for a new firmware but despite a post on the net suggesting there might be a 3.14 version, LG’s OSC says my version is up to date, displaying [3.01, 4.14] as the current one.
Has someone gotten freesync enabled with their display on an AMD framework laptop?
Any ideas what else I could try?
The whole thing started on linux btw, where the output of kscreen-doctor --outputs marked my monitor as Vrr: incapable. drm_info says the same connected via the framework HDMI card. Connected to and usb-c dock with a display port it doesn’t even list the property.
According to this all docks except the steam dock are blocked from offering VRR driver side.
Which for us means we’re basically out of luck since all our ports are essentially docksfrom the driver’s point of view.
This also explains why even connecting via the HDMI expansion card there is no VRR support and also why ony old 2500U it works with a native HDMI port…
Did a bit of digging on this, specifically regarding FreeSync: not supported - from what I can gather, on Windows at least, this feels like a video driver compatibility issue in the case of Windows at least. Your experience in Linux appears to match this, but would require clarification on how you’re connecting as stated below.
When experiencing issues of this nature, we absolutely want to be with an expansion card (HDMI or DP) avoiding docks if issues are experienced. Added layer of complexity.
On Linux (as this is my area), we would check:
lsusb, which will list the expansion cards. We would want to be connected directly HDMI to HDMI expansion card or DP to DP expansion card.
Through your post, I determined you were using KDE, what has your experience been with say, a Live USB of Fedora 39 Workstation (GNOME) for testing direct connections?
Agreed. In case of my HDMI testing, it is with the HDMI expansion card → HDMI cable → display’s HDMI port. It still does not work.
I don’t have a DP expansion card because I didn’t have any use case for it. Got a cheap USB-C to DP cable and with that, it works. So it seems that any indirect connection, even DP-alt-mode-to-HDMI is blocked somehow.
Kind of annoyed AMD makes me spend money unnecessarily, but I can understand they want to limit bug reports for the myriad of broken docks out there… Still, an override parameter would be nice…
I never used GNOME extensively, where would I check if VRR is enabled?
I’ll provide the rest of the output later, limited time at the moment, sadly.
On Linux at least, VRR/FreeSync won’t work over HDMI due to ongoing licensing issues with the HDMI forum and AMD, but should still function over DisplayPort.
I’ll check and see if my FW13/AMD has any issues with FreeSync later today on my Dell monitor and report back.
Edit: VRR/adaptive works just fine in F39 on my AMD Framework 13 via DP on a Dell S2721DGF, does not work via HDMI over TB3.
For me the solution for linux currently is using a direct USB-C to (single!) DisplayPort cable/connection. The DisplayPort expansion card should work as well, but I don’t have one.
I will try to find the code that filters out the docks and check if it works with mine, but according to this, it probably won’t, as my dock is using MST, so it probably has the wonky synaptics chipset.
Now going through an dock containing an MST hub, that’s a whole different issue. The MST hub needs to relay VRR information properly which there could be bugs with the dock firmware.
Currently extremely short on time to look at this, but thank you for the hint (saw your message on the bug as well). Just making sure, the sources there are compiled into the kernel, so I’d have to build a custom kernel with the patch applied, correct?