commit a726915cef1daab57aad4c5b5e4773822f0a4bf8 (drm/i915: resurrect panel lid handling) which is otherwise a relief (it finally makes my X200s detect native external display resolution correctly), seems to conflict with another change in drm code. 1920x1200 is still chosen as it should be, but looks in fact as if it were some badly scaled up non-native resolution, in terminal as well as X. Test results so far: 3.6.11 +patch: all fine 3.7.1 vanilla: wrong std resolution, but sharp graphics once it is set up 3.7.1 +patch: correct std resolution, horrible looks 3.8_rc1-current git (contains the commit): same as above
I should add that this is strictly about the external display - the laptop's LVDS screen is fine in current git master.
I thought you were going to add dmesg, Xorg.log and xrandr...
Created attachment 72267 [details] dmesg_3.8git_extdvi.log I was still putting together logs and rebuilding a kernel image, as some results were inconclusive - one time I didn't even get a terminal with 3.8_rc1 which is possibly unrelated. Attaching logs from 3.8git with ext display connected.
Created attachment 72268 [details] Xorg_3.8git_extdvi.log
Created attachment 72269 [details] xrandr_3.8git_extdvi.log (no difference to 3.6.11+patch xrandr log except for timestamps)
Created attachment 72270 [details] dmesg_3.6.11_extdvi.log dmesg output from my working 3.6.11 kernel image with the above mentioned commit included, which had fixed bug 27622 for me.
Mode choice looks consistent with choosing the 1920x1200 native resolution. Can you please attach a photograph? My guess is that we've accidentally enabled (or left enabled) some pixel doubling or panel fitter...
Created attachment 72274 [details] 3.6.11 vs 3.8git photographs taken and put together for comparison.
Oh, didn't anticipate that difference. Hmm, I think the next step for us is to check the FDI links and see if they are being driven differently between the two kernels. Can you please grab intel-gpu-tools and run intel_reg_dump for 3.6.11/3.8?
Created attachment 72282 [details] intel-reg-dump-3.6.11.log here they are :)
Created attachment 72283 [details] intel-reg-dump-3.8git.log
Gah, that looks like an old version of i-g-t, and doesn't have all the registers I want to check. Can I trouble you to pull from http://cgit.freedesktop.org/xorg/app/intel-gpu-tools and attach again?
Created attachment 72284 [details] intel-reg-dump-3.6.11-v2.log
Created attachment 72286 [details] intel-reg-dump-3.8git-v2.log
Ok, the issue is that the panel fiiter has been left enabled.
Andreas, can you please append drm.debug=6 to your kernel commandline and attach a dmesg from booting 3.8? This may warrant some more debug for I cannot see how we do not clear the PFIT_CONTROL...
Created attachment 72292 [details] dmesg_3.8git_extdvi-drmdebug.log (In reply to comment #16) > Andreas, can you please append drm.debug=6 to your kernel commandline and > attach a dmesg from booting 3.8? Done! That log btw also contains unrelated errors that lead to bug 58876.
Hmm, we need the earliest pieces of dmesg to see what is happening as we detect the LVDS and then disable it. Any chance you can capture the dmesg earlier, or increase the dmesg log size?
Created attachment 72293 [details] dmesg_3.8git_extdvi-drmdebug-v2.log Sorry, I didn't notice the truncated log - new output with increased kernel log buffer.
Ok, so upon booting the BIOS only enables the HDMI output, but notably also setups up the panel fitter on that pipe. As the LVDS is already disable, we forgo disabling it again, and that circumvents turning off the panel fitter.
That explains why booting with i915.panel_ignore_lid=1 and setting up the resolution only later with xrandr works.
Created attachment 72298 [details] [review] Sanitize LVDS upon KMS takeover
Thank you, this bug is fixed for me now. :) Patch applies at 3.7.1 and 3.8git master with only a small change. That leaves me with a new production 3.7.1 image and that other remaining 3.8_rc1+ fbcon bug.
Adding ->sanitize callbacks feels a bit like overkill, and somehow I think it'd be better to handle the pfit like a crtc property as we (somewhat) do on gen5+ already. So can't we just check whether the pfit is enabled on the to-be-disabled pipe in i9xx_crtc_disable and shut it up if it is? I think that'd would mesh better with the future we're heading towards with fastboot&friends ...
Overkill or not, without the patch I still can't use 3.8_rc5. Not a big deal, it's just going to replace the other one that I needed since 2.6.33, but still, I was hoping... :)
Created attachment 74286 [details] [review] disable shared panel fitter for pipe
(In reply to comment #25) > Overkill or not, without the patch I still can't use 3.8_rc5. Not a big > deal, it's just going to replace the other one that I needed since 2.6.33, > but still, I was hoping... :) Hi Andreas, Could you please test the if the patch https://bugs.freedesktop.org/attachment.cgi?id=74286 works for you? It is replacement for 'Sanitize LVDS upon KMS takeover'
First boot into 3.8_rc6 with the new patch applied and there's sharp output. Also no side effects so far. :)
The unmodified patch also works fine with 3.7.6 in conjunction with the 'drm/i915: resurrect panel lid handling' patch.
(In reply to comment #28) > First boot into 3.8_rc6 with the new patch applied and there's sharp output. > Also no side effects so far. :) Thanks!. I will submit the patch for inclusion. May i add Tested-by from you?
Created attachment 74391 [details] dmesg-error.log
(In reply to comment #30) > (In reply to comment #28) > > First boot into 3.8_rc6 with the new patch applied and there's sharp output. > > Also no side effects so far. :) > > Thanks!. I will submit the patch for inclusion. May i add Tested-by from you? You may, but maybe not so fast - attached above one error I've seen in the morning after I had switched off the DP screen for a nightly emerge session and couldn't get X back up - terminal was fine. The function that is touched by the patch is inside the trace.
Fix merged into drm-intel-next, should land in 3.9 and then get backported: commit 79958d2a682740268d505315fd5a33fb11598351 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Fri Feb 8 16:35:37 2013 +0200 drm/i915: disable shared panel fitter for pipe
Thank you very much! So far the patch has been working flawlessly on 3.8_rc7. The X lockup above happened in a patched 3.7.6, but that might not be related.
(In reply to comment #34) > Thank you very much! > > So far the patch has been working flawlessly on 3.8_rc7. The X lockup above > happened in a patched 3.7.6, but that might not be related. Yeah, the lookup is likely unrelated. If you hit it again on latest kernels (your box suffered through some bad regression in 3.7 kernels) please open a new bug with the i915_error_state attached.
A patch referencing this bug report has been merged in Linux v3.9-rc1: commit 24a1f16de97c4cf0029d9acd04be06db32208726 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Fri Feb 8 16:35:37 2013 +0200 drm/i915: disable shared panel fitter for pipe
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.