<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - LG 31MU97 monitor native resolution is 4096x2160, but highest mode found is 3840x2160"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=108081#c12">Comment # 12</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - LG 31MU97 monitor native resolution is 4096x2160, but highest mode found is 3840x2160"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=108081">bug 108081</a>
              from <span class="vcard"><a class="email" href="mailto:ville.syrjala@linux.intel.com" title="Ville Syrjala <ville.syrjala@linux.intel.com>"> <span class="fn">Ville Syrjala</span></a>
</span></b>
        <pre>(In reply to Brian Vincent from <a href="show_bug.cgi?id=108081#c11">comment #11</a>)
<span class="quote">> I've attached the dmesg you asked for, on the new kernel with the patch,
> plus i915.enable_dp_mst=0.  I've also attached the new EDID.  Now that I
> look at it closer, there is another difference.  The number of extensions is
> 1 instead of 2, and the checksum is different.</span >

Yeah. No indication in the logs that anything went wrong. So I guess the
monitor just doesn't care to include the second extension block in SST mode.

So it would appear that only real mystery is why the second extension block
read doesn't give us sensible data in MST mode. Since the no_stop_bit fix
didn't help I'm out of good ideas for now.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the QA Contact for the bug.</li>
          <li>You are the assignee for the bug.</li>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>