<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEEDINFO "
   title="NEEDINFO - LVDS blank screen on GM45"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=94825#c23">Comment # 23</a>
              on <a class="bz_bug_link 
          bz_status_NEEDINFO "
   title="NEEDINFO - LVDS blank screen on GM45"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=94825">bug 94825</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 Rob Kramer from <a href="show_bug.cgi?id=94825#c22">comment #22</a>)
<span class="quote">> (In reply to Ville Syrjala from <a href="show_bug.cgi?id=94825#c21">comment #21</a>)
> > I found something interesting in the opregion spec. Based on that I posted a
> > few patches that could help here:
> > <a href="https://lists.freedesktop.org/archives/intel-gfx/2016-April/091988.html">https://lists.freedesktop.org/archives/intel-gfx/2016-April/091988.html</a>
> > 
> > Please test and report back.

> OK, reverted your previous _DDC patch, applied these three. The result is a
> blank screen. I added some debug statements in your opregion.c patch:

>    ret = swsci(dev, SWSCI_GBDA_PANEL_DETAILS, 0x0, &panel_details);
>    if (ret)
>    {
>            DRM_DEBUG_KMS ("Rob: return %d\n", ret);
>            return ret;
>    }

>    DRM_DEBUG_KMS ("Rob: panel details 0x%x\n", panel_details);

> And in the log:

>   [drm:intel_opregion_get_panel_type] Rob: panel details 0x21000

> Which would mean panel 0x10 according to the spec in your mail, which would
> be good if you'd started counting at 1 :)

> Next, I tried setting the mode to <a href="mailto:1366x768@73.8M">1366x768@73.8M</a> in the bios, and the output
> changes to:

>   [drm:intel_opregion_get_panel_type] Rob: panel details 0x20d00

> That is off by one too, but is still good news since it follows the BIOS
> setting.. Trying the obvious fix works:

>    return ((panel_details >> 8) & 0xff) - 1;

> > "Bits [15:8] - Panel Type
> >  Bits contain the panel type user setting from CMOS
> >  00h = Not Valid, use default Panel Type & Timings from VBT
> >  01h - 0Fh = Panel Number"

> That would mean only 15 possible valid modes, right? But my BIOS has 16 in
> its list already, and the correct mode happens to be the last one.

> [No log attached, because nothing further of interest]</span >

Thanks for testing. I found another version of the spec that says panel type 16
is still valid.

I posted new versions of patches 1 and 3. Please double check that they work
correctly.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
          <li>You are the QA Contact for the bug.</li>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>