On Tue, 27 Dec 2016, Daniel Vetter wrote:
> I'm not sure how this all should look like.
This we definitely agree on, and hence the RFC. :)
I'm pretty sure it should *not* look like it currently does.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Wed, Dec 28, 2016 at 10:39:17AM +0200, Jani Nikula wrote:
> On Tue, 27 Dec 2016, Daniel Vetter wrote:
> > I'm not sure how this all should look like.
>
> This we definitely agree on, and hence the RFC. :)
>
> I'm pretty sure it should *not* look like it currently does.
Yup, agreed on that.
On Tue, Dec 27, 2016 at 06:21:53PM +0200, Jani Nikula wrote:
> Add a replacement for drm_get_edid that handles override and firmware
> EDID at the low level, and handles EDID property update, ELD update, and
> adds modes. This allows for a more transparent EDID override, and makes
> it possible to
Add a replacement for drm_get_edid that handles override and firmware
EDID at the low level, and handles EDID property update, ELD update, and
adds modes. This allows for a more transparent EDID override, and makes
it possible to unify the drivers better. It also allows reusing the EDID
cached in
