Created attachment 29292 [details] Dmesg of wrong resolution/modeline detection, followed by xrandr commands. On an all in one desktop computer, resolution won't be properly detected, and it will show a black band on the right (screen shifted on the left). Running xrandr auto-setting on "VGA1" output fixes it: # xrandr Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096 LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.0*+ 85.0 75.0 70.1 60.0* 832x624 74.6 800x600 85.1 72.2 75.0 60.3 56.2 640x480 85.0 72.8 75.0 59.9 720x400 85.0 640x400 85.1 640x350 85.1 VGA1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 410mm x 230mm 1366x768 60.0 + 1280x720 60.0 1024x768 75.1 70.1 60.0* 800x600 75.0 60.3 640x480 60.0 # xrandr --output VGA1 --auto # xrandr Screen 0: minimum 320 x 200, current 1366 x 768, maximum 4096 x 4096 LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.0*+ 85.0 75.0 70.1 60.0* 832x624 74.6 800x600 85.1 72.2 75.0 60.3 56.2 640x480 85.0 72.8 75.0 59.9 720x400 85.0 640x400 85.1 640x350 85.1 VGA1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 410mm x 230mm 1366x768 60.0*+ 1280x720 60.0 1024x768 75.1 70.1 60.0 800x600 75.0 60.3 640x480 60.0 Lspci of this machine is in attachment 28041 [details] . Please note that to obtain this log, I used Daniel Vetters's intel-gtt-rework branch, that fixed another boot-blocking bug 16891 . Also, this bug might be a regression between 2.6.36-rc2 and 2.6.36-rc3, as previous tests with -rc2 didn't show this behavior.
Created attachment 29302 [details] /sys/kernel/debug/dri/0/i915_opregion
IIRC, the display is connected via the VGA and the LVDS is not actually connected to anything? In which case the VBT is lying and we need to apply a quirk for the false LVDS. Can you attach a dmidecode for the machine?
Indeed, it's an all-in-one computer, but I don't know on which output the screen is connected. xrandr output seems to say it's on VGA1. Also, it's weird, because it used to work with 2.6.34.1 without a quirk. It also worked when I tested Daniel Vetter's branch but that it was based on 2.6.36-rc2. That's why I said I thought it was a regression. Now maybe the code is supposed to behave more "correctly" now and the right way is to add a quirk for this board. I don't know, as I'm not familiar with recent changes. I'll provide dmidecode output on Monday when I have access to the hardware.
Ah, in which case an xrandr when it was working would help confirm which connector they use for the screen. Similarly, it could be the timing snafu fixed in -rc4.
xrandr output on 2.6.34.1 : # xrandr Screen 0: minimum 320 x 200, current 1366 x 768, maximum 4096 x 4096 VGA1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 410mm x 230mm 1366x768 60.0*+ 1280x720 60.0 1024x768 75.1 70.1 60.0 800x600 75.0 60.3 640x480 60.0
Created attachment 30952 [details] Dmidecode output for MSI AE1920 So VGA1 is indeed the default output. In case the preferred solution is to add a quirk, here is the dmidecode output in attachment.
Created attachment 31082 [details] Probe 0xa0 on LVDS port before declaring we attached.
It works (sorry for the delay): [ 21.627039] [drm:intel_lvds_init], LVDS did not respond to DDC probe xrandr output is the same as in comment #5. I tested directly your drm-intel-next branch, which had commit 428d2e828c0a68206e5158a42451487601dc9194 : Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Sep 23 11:16:49 2010 +0100 drm/i915/lvds: Probe DDC on creation Thanks
Now in mainline.