From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Brian Vincent <brainn@gmail.com>, dri-devel@lists.freedesktop.org
Subject: Re: 4096x2160 monitor has EDID reporting 3840x2160
Date: Wed, 26 Sep 2018 15:09:37 +0300 [thread overview]
Message-ID: <20180926120937.GT9144@intel.com> (raw)
In-Reply-To: <87mus4ts5h.fsf@intel.com>
On Wed, Sep 26, 2018 at 02:27:54PM +0300, Jani Nikula wrote:
> On Mon, 24 Sep 2018, Brian Vincent <brainn@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?
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
prev parent reply other threads:[~2018-09-26 12:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-22 21:29 4096x2160 monitor has EDID reporting 3840x2160 Brian Vincent
2018-09-24 6:49 ` Jani Nikula
2018-09-24 22:32 ` Brian Vincent
2018-09-26 11:27 ` Jani Nikula
2018-09-26 12:09 ` Ville Syrjälä [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180926120937.GT9144@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=brainn@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.