Mark,


> I think this is working as designed.

>

> I'll try to find our internal ticket with the details (my memory is a

> bit rusty and this is a few years old now), but as I recall they saw

> issues with Windows testing with 90Hz and so limited the panel to

> 60Hz - using the BIOS EDID to do this. Linux is just following the

> 'manufacturer recommendation'.

>

> If you're not seeing issues, then overriding it to use the panel

> EDID is fine, but just be aware that the 90Hz did not pass Lenovo QA.



Thanks for the context, that's useful to know, and no, I'm not seeing

any issues running at 90Hz so far.



The reason I wanted to flag it rather than just quietly carry the

override locally: this same laptop ran 90Hz without any problems for

about four years across several Ubuntu-based distros (XFCE and KDE

sessions) on older kernels. It was only after switching to an

Arch-based distro with a kernel new enough to carry this patch that I

dropped to 60Hz, and it took a fair amount of EDID diffing to work out

why. So whatever QA issue prompted limiting this panel to 60Hz in the

BIOS EDID, it doesn't seem to have been hit by years of real-world use

at 90Hz on this unit under Linux, for whatever that's worth as a data

point.



Given that, I don't think this needs a behaviour change on your end,

just wanted it on record for anyone else who hits the same "why did my

refresh rate drop after a kernel/distro update" confusion and finds

the ticket. I'll add a note with this context to the GitLab issue.



Thanks again for the quick response.



Narek











From: Mark Pearson <[email protected]>
To: "Narek Sarkissian"<[email protected]>, "Mario 
Limonciello"<[email protected]>
Cc: "Alex Hung"<[email protected]>, "Alexander 
Deucher"<[email protected]>, <[email protected]>, 
<[email protected]>, <[email protected]>, 
<[email protected]>, "Limonciello,  Mario"<[email protected]>, 
"Melissa Wen"<[email protected]>, <[email protected]>
Date: Fri, 28 Aug 2026 20:19:14 +0100
Subject: Re: [PATCH v8 5/5] drm/amd/display: Fetch the EDID from _DDC if 
available for eDP



Hi Narek 
 
On Fri, Aug 28, 2026, at 3:07 PM, Narek Sarkissian wrote: 
> Hi Mario, Alex, Alexander, 
> 
> Following up on this patch (c6a837088bed) with a regression report on a 
> different Lenovo model. 
> 
> On a ThinkPad T14s Gen 3 (AMD Radeon 680M / Rembrandt, DCN 3.1.2), this 
> change causes the internal eDP panel to be capped at 60Hz even though 
> the panel natively supports 90Hz. dm_helpers_read_local_edid() finds 
> an ACPI-provided EDID via _DDC and uses it unconditionally, but on 
> this machine that ACPI blob is a stale/incomplete copy of the panel's 
> real EDID: it encodes only a 60Hz detailed timing, while a live DP AUX 
> read of the same panel (Samsung Display, ATNA40YK08-0) returns 90Hz as 
> the native/preferred timing plus 60Hz as a secondary mode. Both DTDs 
> share the same pixel clock and htotal, so the ACPI copy looks like it 
> was deliberately downclocked rather than being a different display. 
> 
> dmesg confirms the code path taken: 
> 
>   amdgpu 0000:33:00.0: [drm] Using ACPI provided EDID for eDP-1 
> 
> Booting with amdgpu.dcdebugmask=0x8000 (DC_DISABLE_ACPI_EDID) skips 
> the ACPI EDID and forces the live AUX read, which correctly exposes 
> 90Hz and reports the panel's real vendor (Samsung) instead of Lenovo's 
> ACPI-authored EDID (manufacturer/model LEN 16713). 
> 
> Full writeup with the EDID diff (byte-level comparison of the ACPI 
> blob vs. the live-read panel EDID), environment details, and repro 
> steps is here: 
> 
> https://gitlab.freedesktop.org/drm/amd/-/work_items/5710  
> 
> Since this same unconditional ACPI-EDID preference apparently fixes 
> T14 Gen 4 but regresses T14s Gen 3, an unconditional preference in 
> either direction doesn't seem to work for all eDP panels globally. 
> Possible directions raised in the issue: fall back to ACPI only when 
> the live AUX read fails (inverting current priority), prefer whichever 
> source has more/higher-refresh timings, or gate the ACPI-EDID 
> preference behind a DMI-based quirk table scoped to the models that 
> actually need it. 
> 
I think this is working as designed. 
 
I'll try to find our internal ticket with the details (my memory is a bit rusty 
and this is a few years old now), but as I recall they saw issues with Windows 
testing with 90Hz and so limited the panel to 60Hz - using the BIOS EDID to do 
this. Linux is just following the 'manufacturer recommendation'. 
 
If you're not seeing issues, then overriding it to use the panel EDID is fine, 
but just be aware that the 90Hz did not pass Lenovo QA. 
 
Mark

Reply via email to