DRM/AST regression (likely 4.14 -> 4.19+), providing EDID manually fails

[Ilpo Järvinen]

On Mon, 3 Jun 2019, Harish Chegondi wrote:

> On Wed, May 29, 2019 at 01:22:30PM +0300, Jani Nikula wrote:
> > On Wed, 29 May 2019, Ilpo Järvinen <ilpo.jarvinen at cs.helsinki.fi> wrote:
> > > On Tue, 28 May 2019, Jani Nikula wrote:
> > >
> > >> On Mon, 27 May 2019, Ashutosh Dixit <ashutosh.dixit at intel.com> wrote:
> > >> > On Sun, 26 May 2019 12:50:51 -0700, Ilpo Järvinen wrote:
> > >> >>
> > >> >> Hi all,
> > >> >>
> > >> >> I've a workstation which has internal VGA that is detected as AST 2400 and
> > >> >> with it EDID has been always quite flaky (except for some time it worked
> > >> >> with 4.14 long enough that I thought the problems would be past until the
> > >> >> problems reappeared also with 4.14). Thus, I've provided manually the EDID
> > >> >> that I extracted from the monitor using other computer (the monitor itself
> > >> >> worked just fine on the earlier computer so it is likely fine).
> > >> >>
> > >> >> I setup the manual EDID using drm_kms_helper.edid_firmware, however,
> > >> >> after upgrading to 4.19.45 it stopped working (no "Got external EDID base
> > >> >> block" appears in dmesg, the text mode is kept in the lower res mode, and
> > >> >> Xorg logs no longer dumps the EDID info like it did with 4.14). So I guess
> > >> >> the EDID I provided manually on the command line is not correctly put into
> > >> >> use with 4.19+ kernels.
> > >> >>
> > >> >> The 4.19 dmesg indicated that drm_kms_helper.edid_firmware is deprecated
> > >> >> so I also tested with drm.edid_firmware it suggested as the replacement
> > >> >> but with no luck (but I believe also the drm_kms_helper one should have
> > >> >> worked as it was only "deprecated").
> > >> >>
> > >> >> I also tried 5.1.2 but it did not work any better (and with it also tried
> > >> >> removing all the manual *.edid_firmware from the command line so I still
> > >> >> need to provide one manually to have it reliable working it seems).
> > >> >
> > >> > I believe there is a bug already tracking this, here:
> > >> >
> > >> > https://bugs.freedesktop.org/show_bug.cgi?id=107583
> > >> 
> > >> Ilpo, does video=VGA-1:e command-line option work around the problem for
> > >> you?
> > >
> > > Yes it does; together with the modeline stuff for Xorg (after reading the 
> > > referenced bug report I realized I can fix the X side with it). So I now 
> > > have the desired modes/resolutions in use. Thank you all!
> > 
> > Great! It should be enough to just have the replacement firmware EDID
> > for the modes, as long as you have an EDID that represents the
> > capabilities of the display. The modelines for Xorg should not be
> > needed.
> > 
> > BR,
> > Jani.
> > 
> 
> Ilpo,
> 
> I have a patch which I think will fix this problem without needing
> the video=VGA-1:e command-line option work around. Will you be able to
> help me with testing it on your system?
> 
> Thank You!
> Harish.

Yes, if it applies fine to 5.1. ...Also, it will take a week or so.


-- 
 i.