On Mon, 24 Sep 2018, Brian Vincent <brainn@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
