Re: [Intel-gfx] [PATCH 1/2] drm/i915/opregion: add support for mailbox #5 EDID

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/opregion: add support for mailbox #5 EDID
Date: Wed, 2 Sep 2020 13:11:25 +0300	[thread overview]
Message-ID: <20200902101125.GL6112@intel.com> (raw)
In-Reply-To: <87ft814ov8.fsf@intel.com>

On Tue, Sep 01, 2020 at 04:18:19PM +0300, Jani Nikula wrote:
> On Mon, 31 Aug 2020, Jani Nikula <jani.nikula@intel.com> wrote:
> > On Mon, 31 Aug 2020, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> >> On Fri, Aug 28, 2020 at 09:19:40AM +0300, Jani Nikula wrote:
> >>> The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
> >>> used for the embedded display. Add support for using it via the EDID
> >>> override mechanism.
> >>
> >> Abusing the override for this feels a bit odd.
> >
> > It's the least intrusive way to make this work across the drm and driver
> > EDID code that I could think of.
> >
> > BR,
> > Jani.
> >
> >
> >>
> >> Also I have a vague recollection that there was perhaps some
> >> linkage between the mailbox and the ACPI _DDC stuff:
> >> git://github.com/vsyrjala/linux.git acpi_edid
> 
> Only looked at this now. The patch at hand is for actually overriding
> the EDID from the panel, because the panel EDID is readable but bogus.

Do we have an actual use case for this? The commit msg doesn't say so.

> I
> have no idea how the ACPI _DDC stuff would work in this case. Would it
> return the EDID from the panel or from mailbox #5 or something
> completely different? Who knows.
> 
> Using drm_do_get_edid() would of course be doable for reading mailbox #5
> directly as well, but you'd have to make that the "primary" method and
> fall back to the usual drm_get_edid(). Note that this completely
> prevents you from ever reading the actual panel EDID. Using
> edid_override lets you get at the panel EDID too.

Might be nice to make .get_edid() a connector vfunc and let each driver
implement it however they want. That way the driver would be in total
control over the priority of different EDID sources. But haven't really
looked at what that would take. Not even sure if a vfunc is totally
required as I think most EDID reads should be in some connector specific
driver code.

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx