On Wed, 02 Sep 2020, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > On Tue, Sep 01, 2020 at 04:18:19PM +0300, Jani Nikula wrote: >> On Mon, 31 Aug 2020, Jani Nikula <jani.nikula@xxxxxxxxx> wrote: >> > On Mon, 31 Aug 2020, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> 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. It's a bit hazy still, but potentially yes, with a need to backport to stable as well. >> 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. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
