<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <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#c14">Comment # 14</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 <a class="email" href="mailto:ville.syrjala@linux.intel.com" title="Ville Syrjala <ville.syrjala@linux.intel.com>"> Ville Syrjala</a> <pre>(In reply to Rob Kramer from <a href="show_bug.cgi?id=94825#c13">comment #13</a>) > Some things I could try: > > 1) Override broken panel type via module parameter. > 2) Disable VBT via module parameter, force use of existing mode. > 3) Use video=.. parameter to lookup matching VBT panel. The driver is supposed to work without user having to pass parameters. So if we can avoid we'll not be adding any. > > I've tried option 1, hack panel_type to 15 in intel_bios.c, and that works: > > [ 4.770027] [drm:intel_lvds_init] using mode from VBT: > [ 4.770030] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 0 > 148500 1920 2040 2080 2200 1080 1081 1092 1125 0x8 0xa > [ 4.770033] [drm:intel_lvds_init] detected dual-link lvds configuration > > Option 2 also works (hack out VBT setting), but results in messy kernel > warnings/backtraces about pipe state mismatches, see previously attached > logs. Those warns shouldn't happen with <a href="https://lists.freedesktop.org/archives/intel-gfx/2016-April/091392.html">https://lists.freedesktop.org/archives/intel-gfx/2016-April/091392.html</a> There was also a more troubling error in the log [drm:intel_enable_lvds [i915]] *ERROR* timed out waiting for panel to power on but I don't have a decent idea for that now. > > I don't know if option 3 is too horrible to consider. > > I've applied your patch to 4.5 (with minor port), but it returns too early > at: > > ret = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1, > &edid); > if (ret < 0) > return ret; > > Could my kernel be missing some ACPI stuff? There is CONFIG_ACPI_VIDEO=m, > and the module is loaded. I didn't add a new boot log since there wasn't > anything new. If you have some ideas on how to debug this, please let me > know (I know very little about ACPI).. It's possible ACPI doesn't implement the _DDC method on your board. We could check that from the ACPI tables. Can you take an 'acpidump -b', stuff the results into a tarball and attach here? The question I keep asking myself is "if the panel type is genuinely wrong in the VBT, how could Windows work on this board?" Any idea if it does?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>