As I have a black screen with the current 2.6.36 arch linux kernel as soon as KMS kicks in.
I tried a recent git kernel 2.6.37-rc3, there I got a picture but I have a constant flicker all over the screen. This happens in KMS text and in xorg.
It's very very annoying and not really usable.
This is likely to be yet another broken eDP machine. dmesg (with drm.debug=0xe), Xorg.log, xrandr, and intel_reg_dumper would be useful to confirm that and to rule out any other obvious bug.
If it is eDP related, this will probably help:
Author: Chris Wilson <firstname.lastname@example.org>
Date: Mon Nov 29 10:09:55 2010 +0000
Revert "drm/i915/dp: use VBT provided eDP params if available"
which is in -fixes and working its way upstream.
Created attachment 40727 [details]
dmesg output with drm.debug=0xe
Created attachment 40728 [details]
xorg log with flicker
Created attachment 40729 [details]
reverting "drm/i915/dp: use VBT provided eDP params if available" didn't help, still the same behavior.
i'll try to bisect and find the commit responsibly for this bug.
Created attachment 40731 [details]
dmesg output 184.108.40.206 with no flicker
I found the commit responsibly for the flicker:
However this commit also fixes the blank screen problem I have/had.
Another way I fixed the blank screen problem is described here:
(In reply to comment #7)
> I found the commit responsibly for the flicker:
You are 100% convinced that your bisection is correct? Even on a second read, that appears perfectly innocuous for your hardware.
I'm sorry I mixed something up checking out correct branches. This commit isn't the faulty one, will reinvestigate.
I couldn't find the exact commit so far, but I have a small range of commits which introduced the flicker.
I have no flicker with this commit:
but the display remains black a long time, but I don't know the cause of that because I had to patch the function "static void intel_dp_dpms(struct drm_encoder *encoder, int mode)" to see anything at all.
The next commit I could see something again, but WITH flicker was:
leaving following commits for the flicker issue:
* 01cb9ea633ddf3e8770dfe7851e88610087098bc "drm/i915/dp: eDP power sequencing fixes"
* 5c5313c8db9bfb549e080fc4cb0a4c3c2aa7a73d "drm/i915: fix CPU vs PCH eDP confusion"
* 1d85036278f1b3eb3b7c5db805e5c4c847d1415d "drm/i915: remove broken intel_pch_has_edp function"
I also tried to revert some of the commits and build with 7f8232826842b27525857615262f50fe66c84dd7. With following results:
* reverted 5c5313c8db9bfb549e080fc4cb0a4c3c2aa7a73d "drm/i915: fix CPU vs PCH eDP confusion" - still flicker
* reverted 01cb9ea633ddf3e8770dfe7851e88610087098bc "drm/i915/dp: eDP power sequencing fixes" - just a black screen for me, no chance to see a flicker ;)
* reverted 1d85036278f1b3eb3b7c5db805e5c4c847d1415d "drm/i915: remove broken intel_pch_has_edp function" - didn't try yet, because it doesn't look like its responsible for the flicker. but i will try as soon i have time.
I think the first step here is to resolve bug 32005 so we have a semi-working base upon which to investigate.
This one could be fixed by "drm/i915: skip FDI & PCH enabling for DP_A" on intel-gfx.
(In reply to comment #12)
> This one could be fixed by "drm/i915: skip FDI & PCH enabling for DP_A" on
Sorry I'm not able to find this commit. Can you point me to this patch/repo/branch/whatever?
All the relevant patches are now in drm-intel-next: http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git
Sadly I couldn't directly use the drm-intel-next branch, as of now 2.6.38-rc1 doesn't boot on my laptop. But this seems to be completely unrelated to the intel-gfx driver.
891cc2283216bf76f387546f0e220caf8ce9fbf9 Merge branch 'drm-intel-fixes' of git://git./linux/kernel/git/ickle/drm-intel
as base and patched the following patches:
And no flicker anymore!
How likely is a fix for 2.6.37 for this? or do I have to backport the needed patches on my own?
I had one regression report of that series, hence why I put them into -next rather than directly into -fixes. For the time being that's where they will stay, so stick with your working kernel or continue to apply that merge.
-next will be tracking the rc kernels so should become bootable as soon as mainline does, if that is a consolation.