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