4096x2160 monitor has EDID reporting 3840x2160

Jani Nikula jani.nikula at linux.intel.com
Wed Sep 26 11:27:54 UTC 2018


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?

Thanks,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center


More information about the dri-devel mailing list