4096x2160 monitor has EDID reporting 3840x2160

Ville Syrjälä ville.syrjala at linux.intel.com
Wed Sep 26 12:09:37 UTC 2018

On Wed, Sep 26, 2018 at 02:27:54PM +0300, Jani Nikula wrote:
> On Mon, 24 Sep 2018, Brian Vincent <brainn at gmail.com> wrote:
> > Thank you for your reply.  I took your advice and tried it.  None of it
> > really surprises me.
> >
> > The problem seems pretty simple.  There is simply nothing in the EDID that
> > mentions that it's a 4096x2160 monitor.  From looking at the code, I don't
> > see any possible code path that would allow it to somehow discover a mode
> > higher than what the EDID reports.  Even if I did hit the code path that
> > infers new modes, the function valid_inferred_mode will reject any
> > resolution that's higher.  Is there a mechanism for discovering these
> > higher modes that I'm missing?
> >
> > I'm willing to work on a patch that would make this monitor "just work".
> > What I'm interested in is what a patch for this would even look like.  I
> > assume this would need to be added as a "quirk" since the EDID is factually
> > wrong.
> Let's debug this a bit further first. Also, I think an EDID firmware
> (i.e. providing an override EDID from userspace using drm.edid_firmware
> module parameter) would be preferrable to quirking. But first things
> first.
> > Here's the relevant logs:
> We can't see from this short snippet if some modes were pruned
> earlier. A full dmesg would be preferred.
> > Here's my parsed EDID:
> The binary EDID would be preferrable, because the parsed EDID is always
> limited by the parser.
> It would be best to attach such details to a bug report rather than
> pollute the list. Would you mind filing a bug over at [1], referencing
> this thread, and attaching the details there?

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel

Ville Syrjälä

More information about the dri-devel mailing list