4096x2160 monitor has EDID reporting 3840x2160
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
> > 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 , referencing
> this thread, and attaching the details there?
More information about the dri-devel