Created attachment 34275 [details]
photo with wrong colors

Created attachment 34276 [details]
screenshot for comparsion (correct colors)

Created attachment 34277 [details]
lspci

Created attachment 34278 [details]
xrandr output

Created attachment 34279 [details]
inte_reg_dump with drm-intel-next branch

Could you comment out

        if (!lvds_is_present_in_vbt(dev)) {
                DRM_DEBUG_KMS("LVDS is not present in VBT\n");
                return;
        }

in intel_lvds.c and try again?

(In reply to comment #6)
> Could you comment out
> 
>         if (!lvds_is_present_in_vbt(dev)) {
>                 DRM_DEBUG_KMS("LVDS is not present in VBT\n");
>                 return;
>         }
> 
> in intel_lvds.c and try again?

I tried it with drm-intel-next, but nothing changed. xrandr output is the same (except for the 'Timestamp:' part).

Didn't have the time to compare the other output (eg. dmesg) yet.

hi, Zhenyu
   From the vbios.dump attached in https://bugs.freedesktop.org/show_bug.cgi?id=27207#C7 it seems that the panel is connected with eDP instead of LVDS controller.

   Not sure whether the dithering is configured for eDP panel.

thanks.

(In reply to comment #8)
> hi, Zhenyu
>    From the vbios.dump attached in
> https://bugs.freedesktop.org/show_bug.cgi?id=27207#C7 it seems that the panel
> is connected with eDP instead of LVDS controller.
> 
>    Not sure whether the dithering is configured for eDP panel.
> 
> thanks.

But it is not identified as eDP IMHO. HAS_eDP is false in ironlake_crtc_dpms().

This doesn't look like a dithering bug.  It looks like a channel mapping bug.

(In reply to comment #10)
> This doesn't look like a dithering bug.  It looks like a channel mapping bug.

Hi, Ajax
    Can you describe it about the channing mapping more clearly? DP port setting or incorrect mapping between DP and pipe?

Thanks.

(In reply to comment #11)
> (In reply to comment #10)
> > This doesn't look like a dithering bug.  It looks like a channel mapping bug.
> 
> Hi, Ajax
>     Can you describe it about the channing mapping more clearly? DP port
> setting or incorrect mapping between DP and pipe?

I don't know!  Both the FDI registers and the DP registers contain "reversal" bits.  If I had to guess, I'd suspect the DP register first, since if the FDI link were reversed VGA wouldn't look right either.

The reason I say it's likely a channel mapping bug is because the colors in the photo look "swapped" compared to the screenshot: things that would be blue are red, and vice versa.

It would be worth checking if there's a bit in the VBT that tells us what we should do here.

thanks for sharing the idea.

I will look at the VBT and see whether any hint can be found.

Thanks.

(In reply to comment #13)
> thanks for sharing the idea.
> 
> I will look at the VBT and see whether any hint can be found.
> 
> Thanks.

any news on that?

thx ..

I feel that this is a 'MAJOR' bug as the computer is essentially useless with this graphic corruption.  There is no change as of the May 11 intel-drm-next branch.

Will you please try the debug patch https://bugs.freedesktop.org/show_bug.cgi?id=27207#18 on the 2.6.34 kernel and see whether it is helpful?

Please add the boot option of "drm.debug=0x04" and attach the output of dmesg, intel_reg_dumper.

Thanks.

Created attachment 35846 [details]
dmesg output with patch #18

Created attachment 35847 [details]
intel reg dump

(In reply to comment #16)

> Will you please try the debug patch
> https://bugs.freedesktop.org/show_bug.cgi?id=27207#18 on the 2.6.34 kernel and
> see whether it is helpful?
thx alot .. 
colors are correct now in X and the console as well :)

> Please add the boot option of "drm.debug=0x04" and attach the output of dmesg,
> intel_reg_dumper.
nevertheless I've attached the dmesg output:
https://bugs.freedesktop.org/attachment.cgi?id=35846

and the intel_reg_dump output:
https://bugs.freedesktop.org/attachment.cgi?id=35847

I guess I need your address to send you a beer .. ;)

Created attachment 35888 [details]
dmesg with patch #18

Created attachment 35889 [details]
intel reg dump with patch #18

(In reply to comment #16)
> Will you please try the debug patch
> https://bugs.freedesktop.org/show_bug.cgi?id=27207#18 on the 2.6.34 kernel and
> see whether it is helpful?

Kudos, the intel driver works fine now, no funny colors in X and no blurry fonts on the console. :)

Thanks a lot!

Let's hope that the fix will get upstream soon.

Created attachment 35908 [details] [review]
[Patch 1/2] add the support of edp on DP-D of CPT/Ibex

Created attachment 35909 [details] [review]
[Patch 2/2]: configure the pipeconf dithering flag correctly

(In reply to comment #22)
> (In reply to comment #16)
> > Will you please try the debug patch
> > https://bugs.freedesktop.org/show_bug.cgi?id=27207#18 on the 2.6.34 kernel and
> > see whether it is helpful?
> Kudos, the intel driver works fine now, no funny colors in X and no blurry
> fonts on the console. :)
> Thanks a lot!
> Let's hope that the fix will get upstream soon.

thanks for the testing. It is good news that the patch in comment #18 can be helpful to the issue.

Will you please help me test the two patches in comment #23/24 on drm-intel-next tree and see whether it is helpful?

Thanks.

> Will you please help me test the two patches in comment #23/24 on
> drm-intel-next tree and see whether it is helpful?

Hey,
the display works fine with only the first patch applied, having both patches applied works fine as well.

Do you need dmesg and intel reg dump?

(In reply to comment #26)
> > Will you please help me test the two patches in comment #23/24 on
> > drm-intel-next tree and see whether it is helpful?
> 
> Hey,
> the display works fine with only the first patch applied, having both patches
> applied works fine as well.
> 
> Do you need dmesg and intel reg dump?

thanks for the testing. It is unnecessary to attach them again.

The second patch is only to configure the dither flag correctly. If the dither flag is already configured by BIOS, the system can work well. But if we select different crtc for eDP or it is not configured by BIOS, the second patch is required.

Thanks.

*** Bug 27207 has been marked as a duplicate of this bug. ***

When will theses patches get upstream ? I've just tried the 2.6.35-rc3 kernel and I still have random colors.
I'm with the first patch (#16) with 2.6.34 for now and X works really fine but my console goes black when the intel driver is loaded at boot and ctrl+alt+fn doesn't work either (it doesn't show a black screen but my X session, freezed).
Should I try the last patches or do they works the same ? I've attached my dmesg output with drm.debug=0x04

Created attachment 36377 [details]
dmesg output - black console, X ok with patched 2.6.34

Please try current linux-2.6 git master.

Hey,
I tried with a current git master (commit 815c4163b6c8ebf8152f42b0a5fd015cfdcedc78), but the colors are still all wrong.

Do you need any specific debugging output?

Could you try final 2.6.35? there should be fixes there.

Created attachment 37558 [details]
[1/2] dmesg 2.6.35 (garbled colors)

Created attachment 37559 [details]
[2/2] intel_reg_dumper 2.6.35 (garbled colors)

(In reply to comment #33)
> Could you try final 2.6.35? there should be fixes there.
Today I tried compiling 2.6.35 without any patches. I still get purple text on
boot, and the colors in X are garbled.

Up until now I had been using a patched 2.6.34 which works perfectly. I used
the same .config when I compile 2.6.35 today. 

Attached is dmesg with "drm.debug=0x04" enabled and intel_reg_dump.

Same here, 2.6.35 still shows the wrong colors.

On another note, drm-intel-next stopped working as well [which gave the correct colors a few weeks ago]. I'm only getting a black screen now, but could not debug this any further due to some upcoming exams.

Please try 2.6.36-rc1 that I've seen many eDP fix go in.

(In reply to comment #36)
> 
> Up until now I had been using a patched 2.6.34 which works perfectly. I used
> the same .config when I compile 2.6.35 today. 
> 

Which patch works for you?

(In reply to comment #39)
> (In reply to comment #36)
> > 
> > Up until now I had been using a patched 2.6.34 which works perfectly. I used
> > the same .config when I compile 2.6.35 today. 
> > 
> 
> Which patch works for you?

I used a patch from Zhao Yakui that I downloaded from here:
http://lowl.net/wp-content/uploads/2010/06/i915patch.txt.


I will try 2.6.36-rc1 next chance I get. Thanks.

Hello,

I own a Sony VPCZ11 notebook (which is similar to VPCZ12) and can
confirm this bug. I found support from the lowl.net site. I installed
Ubuntu Maverick x86_64 and confirmed non working graphic card.

I recompiled the Ubuntu kernel 2.6.35-12.17 kernel with the following 
two patches:

  * Add the support of eDP on DP-D for Ibex/CPT
    https://patchwork.kernel.org/patch/105706/
  * Configure dither for eDP
    https://patchwork.kernel.org/patch/105707/

and that solves the problem. X is working correctly. I'm almost sure 
that only the first one is required.

Since that, I tried to recompile several kernels without success:

* 2.6.35-14.19 with patch #105706
* 2.6.35-14.19 with patch #105706 and https://bugs.freedesktop.org/attachment.cgi?id=37049
* 2.6.35-14.19 with drm-net patch from 20100804
* vanilla 2.6.35 with drm-net patch from 20100804

As you I noticed that 2.6.36-rc1 has many eDP fix but it does not work
either (screen goes black and seems off).

increase priority

(In reply to comment #41)
> I recompiled the Ubuntu kernel 2.6.35-12.17 kernel with the following 
> two patches:
> 
>   * Add the support of eDP on DP-D for Ibex/CPT
>     https://patchwork.kernel.org/patch/105706/
>   * Configure dither for eDP
>     https://patchwork.kernel.org/patch/105707/
> 
> and that solves the problem. X is working correctly. I'm almost sure 
> that only the first one is required.

I'm a little confused, so first one could fix the problem for you, and it's already in upstream. Does 2.6.36-rc2 work for you? If not, could you bisect which commit causes regression?

(In reply to comment #43)

> I'm a little confused, so first one could fix the problem for you, and it's
> already in upstream. Does 2.6.36-rc2 work for you? If not, could you bisect
> which commit causes regression?

I just tried a vanilla 2.6.36-rc3 and it does not fix the problem.

I don't know how to "bisect" commit between the 2.6.35-12-generic from ubuntu and a vanilla 2.6.36-rc3. I am able to use diff and patch but I don't know how to help more.

Hey,
I tried bisecting the problem (with git bisect start -- drivers/gpu), but for now only to the commit that reintroduced the wrong colors.

Git says that 1073af33fdd4e960c70b828e899b1291b44f0b3d is at fault, which is IMHO a bit wierd, considering that it only touches the intel_lvds.c file.

My bisecting log:
# bad: [2bfc96a127bc1cc94d26bfaa40159966064f9c8c] Linux 2.6.36-rc3
git bisect bad 2bfc96a127bc1cc94d26bfaa40159966064f9c8c
# good: [36e83a187ca7517e9bdce7148b1c2c27661ef38f] drm/i915: Add the support of eDP on DP-D for Ibex/CPT
git bisect good 36e83a187ca7517e9bdce7148b1c2c27661ef38f
# bad: [5ddb954b9ee50824977d2931e0ff58b3050b337d] drm/i915/edp: Flush the write before waiting for PLLs
git bisect bad 5ddb954b9ee50824977d2931e0ff58b3050b337d
# bad: [7b824ec2e5d7d086264ecae51e30e3c5e00cdecc] drm/i915: Clear the Ironlake dithering flags when the pipe doesn't want it.
git bisect bad 7b824ec2e5d7d086264ecae51e30e3c5e00cdecc
# bad: [2bd34f6ca86b5a5f9b749624f73310820e7a93fd] Merge remote branch 'origin/master' into drm-intel-next
git bisect bad 2bd34f6ca86b5a5f9b749624f73310820e7a93fd
# good: [e1a4474349997d722e4ae64e40a68feb25307109] drm/i915/pch: Cosmetic fix to FDI link training
git bisect good e1a4474349997d722e4ae64e40a68feb25307109
# bad: [aebf0dafee1a0a22b3d25db8107c6479db4aaebe] drm/i915: don't free non-existent compressed llb on ILK+
git bisect bad aebf0dafee1a0a22b3d25db8107c6479db4aaebe
# bad: [6ba770dc5c334aff1c055c8728d34656e0f091e2] drm/i915: Make G4X-style PLL search more permissive
git bisect bad 6ba770dc5c334aff1c055c8728d34656e0f091e2
# bad: [6f772d7e2f4105470b9f3d0f0b26f06f61b1278d] drm/i915: Explosion following OOM in do_execbuffer.
git bisect bad 6f772d7e2f4105470b9f3d0f0b26f06f61b1278d
# bad: [1073af33fdd4e960c70b828e899b1291b44f0b3d] gpu/drm/i915: Add a blacklist to omit modeset on LID open
git bisect bad 1073af33fdd4e960c70b828e899b1291b44f0b3d


I'll try to bisect the black screen issue next week.

I think this regression should be caused by

commit b329530ca7cdf6bf014f2124efd983e01265d623
Author: Adam Jackson <ajax@redhat.com>
Date:   Fri Jul 16 14:46:28 2010 -0400

    drm/i915/dp: Correctly report eDP in the core connector type
    
    Do this for both real eDP and for PCH_DP_D when used as the eDP
    connection.
    
    Signed-off-by: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Eric Anholt <eric@anholt.net>

please help to test by revert that commit, thanks.

Created attachment 38402 [details] [review]
Revert patch as requested on comment #46


I compiled a 2.6.36rc3 vanilla kernel with the revert patch as requested and I always get a blackscreen.

Patch attached. Packages of the kernel are available there:

http://ombos.raceme.org//tof/i915-vpcz1/2.6.36-rc3-2/

I don't know if it can be usefull but I included two xorg log files:

- xorg.1 from a working session
- xorg.2 from a non working session

The blank screen still reproduces on Sony Vaio VPC-Z11X9R and linux-2.6.36-rc4.

(lower priority to not block Q3 release...)

I suspect there're actually two kinds of eDP bugs here. One for eDP output from CPU directly, and another for eDP output from PCH. Ajax's patch only affect PCH eDP, but current upstream has regression for CPU eDP as well...I'll try to see if we can find proper hw to reproduce this.

(In reply to comment #49)

> I'll try to see if we can find proper hw to reproduce this.

I can give you ssh access to my Sony VPCZ11 if this can help. Please contact me privately for details if interrested.

If Christophe's laptop didn't satisfy you by any reason, I can also give you access to my vpc-z11x9r (with slackware linux and vanilla kernel installed).

No luck with linux-2.6.36-rc7 :(

It works fine with a (relatively) current drm-intel-next. The black screen bug is gone now, so we can actually tell that the colors are fine. :)

Where can I get it? 
Is it the drm-intel git repository?

If so, the screen is blank with it.

This is a correct bootup log:
Oct 14 09:58:44 vaio kernel: i915 0000:00:02.0: power state changed by ACPI to D0
Oct 14 09:58:44 vaio kernel: i915 0000:00:02.0: power state changed by ACPI to D0
Oct 14 09:58:44 vaio kernel: i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Oct 14 09:58:44 vaio kernel: mtrr: no more MTRRs available
Oct 14 09:58:44 vaio kernel: [drm] MTRR allocation failed.  Graphics performance may suffer.
Oct 14 09:58:44 vaio kernel: [drm] set up 127M of stolen space
Oct 14 09:58:44 vaio kernel: fb0: inteldrmfb frame buffer device
Oct 14 09:58:44 vaio kernel: registered panic notifier
Oct 14 09:58:44 vaio kernel: acpi device:00: registered as cooling_device4
Oct 14 09:58:44 vaio kernel: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input6
Oct 14 09:58:44 vaio kernel: ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
Oct 14 09:58:44 vaio kernel: [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0


This is a blank screen bootup log:
Oct 14 09:57:22 vaio kernel: [drm] Initialized drm 1.1.0 20060810
Oct 14 09:57:22 vaio kernel: i915 0000:00:02.0: power state changed by ACPI to D0
Oct 14 09:57:22 vaio kernel: i915 0000:00:02.0: power state changed by ACPI to D0
Oct 14 09:57:22 vaio kernel: i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Oct 14 09:57:22 vaio kernel: mtrr: no more MTRRs available
Oct 14 09:57:22 vaio kernel: [drm] MTRR allocation failed.  Graphics performance may suffer.
Oct 14 09:57:22 vaio kernel: [drm] detected 127M stolen memory, trimming to 32M
Oct 14 09:57:22 vaio kernel: [drm] set up 32M of stolen space
Oct 14 09:57:22 vaio kernel: vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
Oct 14 09:57:22 vaio kernel: No connectors reported connected with modes
Oct 14 09:57:22 vaio kernel: [drm] Cannot find any crtc or sizes - going 1024x768
Oct 14 09:57:22 vaio kernel: fb0: inteldrmfb frame buffer device
Oct 14 09:57:22 vaio kernel: drm: registered panic notifier
Oct 14 09:57:22 vaio kernel: acpi device:00: registered as cooling_device4
Oct 14 09:57:22 vaio kernel: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input4
Oct 14 09:57:22 vaio kernel: ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
Oct 14 09:57:22 vaio kernel: [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

I can ssh to the blank screen bootup and do some commands there.

(In reply to comment #54)
> Where can I get it? 
> Is it the drm-intel git repository?
> 
> If so, the screen is blank with it.

You can get it here: git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel

And check it out via: `git clone git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel'

You can check out the 'drm-intel-next' branch with `git checkout drm-intel-next', but it might be the default anyway.

> You can check out the 'drm-intel-next' branch with `git checkout
> drm-intel-next', but it might be the default anyway.

I managed to download the -next branch (http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git;a=shortlog;h=refs/heads/drm-intel-next) and compile it. Indeed the black screen bug is resolved: X is fully working.

If one wants to test I made linux-image packages for ubuntu maverick 64bits:

http://ombos.raceme.org/tof/i915-vpcz1/2.6.36-rc5-tiphon.2/

Yes, intel-drm-next works for me!

But my xrandr outputs:
borisko@vaio:~$ xrandr
Screen 0: minimum 320 x 200, current 1600 x 900, maximum 8192 x 8192
(null)1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 291mm x 164mm
   1600x900       59.9*+   40.0  
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
HDMI3 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)

is it ((null)1) correct?

Mark as closed with upstream bits. Please also test with 2.6.37-rc kernel too to make sure the fix in drm-intel-next is not missed.

thanks.

2.6.37-rc1-git11 works fine.

But the bug with the name ((null)1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 291mm x 164mm) still exist.

I have a lot of messages in dmesg on 2.6.37-rc1-git11:
[drm:i915_gem_mmap_gtt_ioctl] *ERROR* Attempting to mmap a purgeable buffer
[drm:i915_gem_object_bind_to_gtt] *ERROR* Attempting to bind a purgeable object

Also, black screen problem returns in linux-2.6.37-rc5.

Linux 2.6.37 has blank screen problem.

Not the same bug, so please reopen another. However you might be interested in

commit 369581028e2528122cc109abacf11766ae231f01
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue Jan 4 10:46:49 2011 -0800

    drm/i915: check eDP encoder correctly when setting modes
    
    We were using a stale pointer in the check which caused us to use CPU
    attached DP params when we should have been using PCH attached params.
    
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31988
    Tested-by: Jan-Hendrik Zab <jan@jhz.name>
    Tested-by: Christoph Lukas <christoph.lukas@gmx.net>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>