Created attachment 125278 [details] dmesg kernel 4.7-rc7 With kernel 4.7-rc7 (drm-intel-nightly) laptop screen (LVDS) goes blank after inteldrmfb is loaded. 4.7.0-rc7+ #1 SMP Sat Jul 23 16:05:00 CEST 2016 x86_64 x86_64 x86_64 GNU/Linux It appears to me the problem is with setting panel to wrong mode: [ 2.737896] [drm:parse_lfp_panel_data] Found panel mode in BIOS VBT tables: [ 2.737900] [drm:drm_mode_debug_printmodeline] Modeline 0:"1366x768" 0 76110 1366 1397 1462 1560 768 772 784 814 0x8 0xa [ 2.737902] [drm:parse_lfp_panel_data] VBT initial LVDS value 300 While with previous kernel, 4.6, there was: [ 4.684175] [drm:parse_lfp_panel_data] Found panel mode in BIOS VBT tables: [ 4.684177] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 0 144200 1920 1968 2040 2116 1080 1083 1088 1137 0x8 0xa [ 4.684178] [drm:parse_lfp_panel_data] VBT initial LVDS value 33c My notebook uses fullhd panel, so resolution should be 1920x1080 clearly. Full dmesg obtained with drm.debug=0xe is attached.
Created attachment 125279 [details] dmesg kernel 4.6 dmesg from kernel 4.6 for comparison.
I can confirm the issue for the 4.7.0 version. I get the same wrong resolution and the display stays blank.
A bisect gave me the commit 'drm/i915: Get panel_type from OpRegion panel details' (a05628195a0d9f3173dd9aa76f482aef692e46ee), which introduced the blank panel.
Also an issue on Fujitsu Lifebook E744. Last known good kernel 4.6.7; still bad on 3.8-rc5. I was unable to cleanly revert a05628195a0d9f3173dd9aa76f482aef692e46ee to validate the bisection. However, the problem is identical, the modeline that is chosen is an incorrect, lower resolution: -[drm:drm_mode_debug_printmodeline] Modeline 0:"1600x900" 0 107800 1600 1648 1 680 1920 900 903 908 936 0x8 0xa -[drm:parse_lfp_panel_data] VBT initial LVDS value 30033c +[drm:drm_mode_debug_printmodeline] Modeline 0:"1366x768" 0 70000 1366 1402 1438 1476 768 772 780 790 0x8 0xa +[drm:parse_lfp_panel_data] VBT initial LVDS value 300
Created attachment 126227 [details] 4.8-rc3 bad
Created attachment 126228 [details] 4.6.7 good
Another report of the same disguised as a patch http://patchwork.freedesktop.org/patch/msgid/1472398126-1095-2-git-send-email-aarcange@redhat.com We need to revert.
Both these two need to be reverted: commit aeddda06c1a704bb97c8a7bfe7a472120193bd56 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Jul 12 15:00:37 2016 +0300 drm/i915: Ignore panel type from OpRegion on SKL commit a05628195a0d9f3173dd9aa76f482aef692e46ee Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Apr 11 10:23:51 2016 +0300 drm/i915: Get panel_type from OpRegion panel details
I was just getting hopeful that we might go with gen>=5 check since that would preserve the opregion handling for the original g4x machine which clearly needed it. Unfortunately bug 97443 says a 965gm regressed as well, so that plan won't work either :(
Also bug 97363.
Can you try git://github.com/vsyrjala/linux.git opregion_panel_type_stuff I'm not expecting it would really fix the problem, but it will at least show us the full response from the BIOS.
Created attachment 126251 [details] cleaned dmesg 'opregion_panel_type_stuff' build on Sandy Bridge @Ville I tried your kernel tree on my i7-2640M machine.
(In reply to Marco Krüger from comment #12) > Created attachment 126251 [details] > cleaned dmesg 'opregion_panel_type_stuff' build on Sandy Bridge > > @Ville I tried your kernel tree on my i7-2640M machine. Thanks. I pushed a new patch to the branch which I think should get us back on track with your machine. So please pull again, and retest. I don't really know if it's any more correct than the current code though, and I don't yet know if it works for the original machine that needs the opregion panel type.
Created attachment 126254 [details] dmesg kernel 4.8.0-rc4+
Created attachment 126255 [details] cleaned dmesg patched version Patched version works for me.
I had to resort to a quirk to fix this for all machines. Please test this branch: git://github.com/vsyrjala/linux.git opregion_panel_type_quirk
Created attachment 126312 [details] cleaned dmesg quirk version Quirk version does work for me as well.
(In reply to Marco Krüger from comment #17) > Created attachment 126312 [details] > cleaned dmesg quirk version > > Quirk version does work for me as well. I had to revise the patch a bit more to make it actually work on the original machine that needs the quirk: git://github.com/vsyrjala/linux.git opregion_panel_type_quirk_2 Please test to make sure I didn't fumble anything for other machines. Fingers crossed that this is the last revision...
(In reply to Ville Syrjala from comment #18) > I had to revise the patch a bit more to make it actually work on the > original machine that needs the quirk: > git://github.com/vsyrjala/linux.git opregion_panel_type_quirk_2 > > Please test to make sure I didn't fumble anything for other machines. > Fingers crossed that this is the last revision... Can confirm that it works now with my machine either (opregion_panel_type_quirk_2).
Created attachment 126373 [details] dmesg kernel 4.8.0-rc4+ opregion_panel_type_quirk_2
Created attachment 126415 [details] cleared dmesg quirk2 version Yep, quirk2 is working, too.
Patch submitted and under review: https://patchwork.freedesktop.org/series/12380/
Resolving as fixed and waiting for patch to be merged and tested to close it.
(In reply to yann from comment #23) > Resolving as fixed and waiting for patch to be merged and tested to close it. Please let's resolve fixed only after the patch has been merged. Thanks.
Fixed by commit ea54ff4008892b46c7a3e6bc8ab8aaec9d198639 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Sep 13 12:22:19 2016 +0300 drm/i915: Ignore OpRegion panel type except on select machines in drm-intel-fixes.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.