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

[Jani Nikula <jani.nikula@linux.intel.com>]

On Mon, 03 Jun 2019, Harish Chegondi <harish.chegondi@intel.com> wrote:
> On Wed, May 29, 2019 at 01:22:30PM +0300, Jani Nikula wrote:
>> On Wed, 29 May 2019, Ilpo Järvinen <ilpo.jarvinen@cs.helsinki.fi> wrote:
>> > On Tue, 28 May 2019, Jani Nikula wrote:
>> >
>> >> On Mon, 27 May 2019, Ashutosh Dixit <ashutosh.dixit@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?

Alas the patch you provided in the referenced bugzilla will regress in
other ways; specifically losing the ability to use DDC probe for
detecting displays. This is very old happy day scenario functionality
that should not be messed with.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel