On Wed, Sep 26, 2018 at 02:27:54PM +0300, Jani Nikula wrote: > 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? [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel -- Ville Syrjälä Intel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
