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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 29, 2019 at 01:22:30PM +0300, Jani Nikula wrote:
> On Wed, 29 May 2019, Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxx> wrote:
> > On Tue, 28 May 2019, Jani Nikula wrote:
> >
> >> On Mon, 27 May 2019, Ashutosh Dixit <ashutosh.dixit@xxxxxxxxx> 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.

> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-de�;[
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux