[GMA950] external lcd does not work on high resolution

[marcello100]

I have Acer Aspire 5710Z with Intel GMA950 graphic card and VGA out. Last week I bought a new lcd monitor Samsung SyncMaster 2343nw with VGA input and with resolution of 2048x1152. My operating system is Ubuntu 8.10

When I plugged it in, I can only get 1440x900 out of that external lcd with 1200x800 on internal monitor. I changed Virtual resolution in xorg.conf to 2048x2048(maximum for GMA) and set my external monitor to be on top. I can get then 2 monitors with extended desktop and Compiz fully working, but anything above 1440x900 resolution on external lcd cause some strange artefacts on it. I can't see anything there on that desktop.

I configure only the virtual resolution in xorg.conf and resolution in gnome with "screen resolution" applet.

I was quite interested, how well would it work on Windows. XP no problem, now using Vista with 2048x1152, so it is possible, it's not that my card is not possible to drive it or the DAC is weak.

Any solution? Is it bad configuration or bug in driver?

[marcello100 (12312-azet)]

Now using Ubuntu 9.04. Will try 9.10 alpha 2, I don't thing it's solved yet. This happened also in Fedora 11 I tried.

[marcello100 (12312-azet)]

And I forgot to say, that on my 2nd PC with poor intel atom and GMA950 it works flawlessly. However, My main PC, Acer sucks with this. Any ideas?

[marcello100 (12312-azet)]

with uxa I can get only 1280x960. Exa will be in future releases deprecated.

[Bryce Harrington (bryce)]

Hi 12312-azet,

Thanks for including an image to demonstrate the issue. Could you also please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log or Xorg.0.log.old file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[marcello100 (12312-azet)]

xorg log just BEFORE my ext. monitor was connected

[marcello100 (12312-azet)]

xorg after the monitor was configured to high res.

[marcello100 (12312-azet)]

xorg.conf has little or no change

[marcello100 (12312-azet)]

I was trying to do this. It printed no errors after applying changes.

[marcello100 (12312-azet)]

Today I tried Ubuntu 9.10 Alpha 2.

No change at all.. Only loss of wallpaper and everything except the cursor, which was normal in laptop screen and horizontally distorted on 2nd monitor. I tried EXA and UXA also.

Offtopic: performance on glxgears was once 1000FPS, now on 9.04 about 400, and 9.10 300 on exa and uxa also.

I know it's, it's alpha.

It's weird, that on my Atom based PC HD works just fine, on Acer with Core2 with the same graphic card it don't.

[Bryce Harrington (bryce)]

Forwarding this bug from Ubuntu reporter marcello100:
http://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/349412

[Problem]
External lcd maximum resolution is 1440x900 instead of 2048x1152.

[Original Description]
I have Acer Aspire 5710Z with Intel GMA950 graphic card and VGA out. Last week I bought a new lcd monitor Samsung SyncMaster 2343nw with VGA input and with resolution of 2048x1152. My operating system is Ubuntu 8.10

When I plugged it in, I can only get 1440x900 out of that external lcd with 1200x800 on internal monitor. I changed Virtual resolution in xorg.conf to 2048x2048(maximum for GMA) and set my external monitor to be on top. I can get then 2 monitors with extended desktop and Compiz fully working, but anything above 1440x900 resolution on external lcd cause some strange artefacts on it. I can't see anything there on that desktop.

I configure only the virtual resolution in xorg.conf and resolution in gnome with "screen resolution" applet.

I was quite interested, how well would it work on Windows. XP no problem, now using Vista with 2048x1152, so it is possible, it's not that my card is not possible to drive it or the DAC is weak.

Today I tried Ubuntu 9.10 Alpha 2. No change at all.. Only loss of wallpaper and everything except the cursor, which was normal in laptop screen and horizontally distorted on 2nd monitor. I tried EXA and UXA also.

[Bryce Harrington (bryce)]

Created an attachment (id=28110)
This happens on the screen screen.jpg

[Bryce Harrington (bryce)]

Created an attachment (id=28111)
xorg log just BEFORE my ext. monitor was connected

[Bryce Harrington (bryce)]

Created an attachment (id=28112)
xorg after the monitor was configured to high res.

[Bryce Harrington (bryce)]

Created an attachment (id=28113)
I was trying to do this. It printed no errors after applying changes.

[Michael Fu (michael-fu-intel)]

need a xorg.log, with option "modedebug" "true" set in xorg.conf..

[Bryce Harrington (bryce)]

Thanks Marcello, I've forwarded your bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=22996 - please subscribe to this bug in case upstream needs further information or wishes you to test something. Thanks ahead of time!

[Marcel-kanta (marcel-kanta)]

Created an attachment (id=28126)
xorg.log with modedebug

xorg.log provided

[Marcel-kanta (marcel-kanta)]

Created an attachment (id=28127)
xorg.log with modedebug

previous xorg.log was from Ubuntu 9.04
this one is from Ubuntu 9.10 Alpha 3 with the same config file.

[Michael Fu (michael-fu-intel)]

Section "Device"
 ...
        Option "monitor-LVDS" "LVDS"
        Option "monitor-TV" "TV"
        Option "Modedebug" "True"
        ...
EndSection
        ...
Section "Monitor"
        Identifier "LVDS"
        Option "Ignore" "True"
EndSection

Section "Monitor"
        Identifier "TV"
        Option "Ignore" "True"
EndSection

On Ubuntu 9.04 , Would you please add this to your xorg.conf and have a try if it works? this should leave only the VGA port enabled. you can remove the VGA section in your xorg.conf, if you have... Please attach your xorg.conf and xorg.log.

Note: on 9.04, not 9.10 alpha... we will eventually fix this for 9.10 but this would help us narrow things down. thanks.

[Marcel-kanta (marcel-kanta)]

I did, what you asked me to do. I tried Ubuntu 9.04, monitor on laptop was off as it should and ext. monitor was on, but the log in screen was distorted, like on the picture I provided.

Here is the xorg.conf and xorg.log (log was captured when CTRL-SHIFT F1 after log in screen).

[Marcel-kanta (marcel-kanta)]

Created an attachment (id=28170)
xorg.conf with only ext. monitor on

[Marcel-kanta (marcel-kanta)]

Created an attachment (id=28171)
Xorg.0.log with only ext. monitor on

[Michael Fu (michael-fu-intel)]

from the regdump, it looks like fifo issue...

[Marcel-kanta (marcel-kanta)]

Do you want some more info, logs?

part of lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

I have one more PC with GMA950, which can do on any Ubuntu the max. resolution.
its lspci
00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82945G/GZ/P/PL PCI Express Root Port (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)

[Michael Fu (michael-fu-intel)]

(In reply to comment #13)
> Do you want some more info, logs?
>
> part of lspci
> 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and
> 945GT Express Memory Controller Hub (rev 03)
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS,
> 943/940GML Express Integrated Graphics Controller (rev 03)
> 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML
> Express Integrated Graphics Controller (rev 03)
>
> I have one more PC with GMA950, which can do on any Ubuntu the max. resolution.
> its lspci
> 00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub
> (rev 02)
> 00:01.0 PCI bridge: Intel Corporation 82945G/GZ/P/PL PCI Express Root Port (rev
> 02)
> 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated
> Graphics Controller (rev 02)
>

Do you mean your Samsung monitor can work with no problem on this machine? If so, please repeat the steps on comment# 8 and attach the xorg.log. It'll be helpful for us to compare its log with your Acer machine. thanks.

[Marcel-kanta (marcel-kanta)]

Created an attachment (id=28226)
Xorg.0.log from another working PC

> Do you mean your Samsung monitor can work with no problem on this machine? If
> so, please repeat the steps on comment# 8 and attach the xorg.log. It'll be
> helpful for us to compare its log with your Acer machine. thanks.
>

Yes, another PC with GMA950 works without problems with Samsung monitor.
Here's its xorg.log. It's Intel Atom based PC w. 1GB RAM.

[Michael Fu (michael-fu-intel)]

(In reply to comment #8)
> Section "Device"
> ...
> Option "monitor-LVDS" "LVDS"
> Option "monitor-TV" "TV"
> Option "Modedebug" "True"
> ...
> EndSection
> ...
> Section "Monitor"
> Identifier "LVDS"
> Option "Ignore" "True"
> EndSection
>
> Section "Monitor"
> Identifier "TV"
> Option "Ignore" "True"
> EndSection
>
>
> On Ubuntu 9.04 , Would you please add this to your xorg.conf and have a try if
> it works? this should leave only the VGA port enabled. you can remove the VGA
> section in your xorg.conf, if you have... Please attach your xorg.conf and
> xorg.log.
>
> Note: on 9.04, not 9.10 alpha... we will eventually fix this for 9.10 but this
> would help us narrow things down. thanks.
>

with this environment as above, what if you add

Option "FrameBufferCompression" "False"

will it work? thanks.

[Marcel-kanta (marcel-kanta)]

Created an attachment (id=28380)
xorg.log - Option "FrameBufferCompression" "False"

No change, it didn't fix it.

[Michael Fu (michael-fu-intel)]

see if Jesse has any idea...

[Jesse Barnes (jbarnes-virtuousgeek)]

If it's FIFO related, it should either be fixed by recent kernel bits or by the patch in bug #22921. Can you test?

[Marcel-kanta (marcel-kanta)]

I will when the Ubuntu 9.10 stable comes out. In older kernels there's no /intel_display.c , so I can't patch it. I'm looking forward to it.

[Jesse Barnes (jbarnes-virtuousgeek)]

Assuming this one is fixed by the recent FIFO updates to the kernel.

[Bryce Harrington (bryce)]

Upstream has closed the bug on their end due to lack of response to their questions and because they believe it to now be fixed. Please reopen if you find it to still be an issue.

Also, according to the final comment on the upstream bug, it sounds like this is an issue in the kernel rather than the ddx driver, so re-filing.

[Marcel-kanta (marcel-kanta)]

I tried Ubuntu 9.10 RC with the 2.6.31-14.48 kernel based on 2.6.31.1.

no, I can't get high resolution from it, should I? What kernel should fix my
problem? What version of graphic driver?

Regards

Marcel

[Jesse Barnes (jbarnes-virtuousgeek)]

Actually looking at this again it sounds like a rendering issue. Does the same problem occur if you disable compiz? If so maybe our render accel is broken?

[Marcel-kanta (marcel-kanta)]

Created an attachment (id=30704)
video of the bug

I just tried it without compiz and only on 1 monitor. Still the same bug.

[Karl Ljungkvist (k-ljungkvist)]

Hi, I just wanted to say that I also have the exact same problem. And it can't be related to compiz (I use dwm). I first do

xrandr --output VGA --preferred --output LVDS --off

and then (blindly)

xrandr --output VGA --off --output LVDS --preferred

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=30707)
Lines added to Xorg.0.log

When running the said commands these are the lines added to Xorg.0.log.

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=30708)
Output of xrandr -q

...and this is the output produced by xrandr -q when the external monitor is plugged in.

[Marcel-kanta (marcel-kanta)]

Do you have the same graphic card?
(In reply to comment #25)
> Hi, I just wanted to say that I also have the exact same problem.

[Karl Ljungkvist (k-ljungkvist)]

(In reply to comment #28)
> Do you have the same graphic card?

lspci says:

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

which looks identical to yours.

[Jesse Barnes (jbarnes-virtuousgeek)]

Maybe this was fixed by this kernel commit?

commit 629598da932cfa5ff398fe10bc123282a6f3049e
Author: Jesse Barnes <email address hidden>
Date: Tue Oct 20 07:37:32 2009 +0900

    drm/i915: update watermarks before enabling PLLs

[Karl Ljungkvist (k-ljungkvist)]

(In reply to comment #30)
> Maybe this was fixed by this kernel commit?
>
> commit 629598da932cfa5ff398fe10bc123282a6f3049e
> Author: Jesse Barnes <email address hidden>
> Date: Tue Oct 20 07:37:32 2009 +0900
>
> drm/i915: update watermarks before enabling PLLs
>

I'm sorry but I'm pretty new to these kind of things. I use 'stock' ubuntu, what would i have to do to try out if it works?

[Jesse Barnes (jbarnes-virtuousgeek)]

Oh sorry for the slow reply. Ubuntu has a "bleeding edge" kernel repo somewhere you can use for testing whether there's an upstream bug for a fix. You'll have to search around launchpad for it though; I don't remember the name offhand.

[Jesse Barnes (jbarnes-virtuousgeek)]

Assuming this is fixed or a hardware limitation (945 limits you to 2048x2048 max, so if you have a 1280 or wider external display you'll likely exceed its limits).

[Karl Ljungkvist (k-ljungkvist)]

(In reply to comment #33)
> Assuming this is fixed or a hardware limitation (945 limits you to 2048x2048
> max, so if you have a 1280 or wider external display you'll likely exceed its
> limits).
>

As for me it still doesn't work; I'm now running Arch Linux with kernel version 2.6.32.7-1, and xf86-video-intel version 2.9.1-1. I still haven't learned how to check bleeding edge versions though (I'll see if I can find some time).

In my case, it works fine on resolutions (up to and including) 1440x900 and 1280x1024, but at resolutions 1680x1050 and 1920x1080, I get the behavior explained above. Note that this is when _only_ using the external one, i.e. issuing

  xrandr --output --mode ... --output LVDS --off

Also, since it works with Windows XP on the same machine it can't really be the hardware.

My current xorg.conf:

Section "Device"
        Identifier "Card0"
        Driver "intel"
EndSection

[Jesse Barnes (jbarnes-virtuousgeek)]

Ok, re-opening. Can you capture a register dump from the working and broken cases and report which resolutions you had set?

[Ts+freedesktop-bugzilla (ts+freedesktop-bugzilla)]

Ah, same problem here:

System environment:
-- chipset: 945GM
-- system architecture: 32-bit, i686
-- xf86-video-intel: 2.9.1
-- xserver: 1.6.3
-- libdrm: 2.4.15
-- kernel: 2.6.33rc8
-- Linux distribution: Ubuntu 9.04 (Jaunty)
-- Machine or mobo model: Lenovo ThinkPad R60e
-- Display connector: VGA

Reproducing steps:

Laptop is a ThinkPad R60e. External VGA monitors with a native resolution like 1600x1200 or 1920x1080 results in unusable screen flickering if native mode is used. Some smaller resolutions like 1440x900 do work.

I've tested some configurations:
 - Ubuntu 9.04 (Jaunty) with default kernel, default X.org and intel driver
 - Jaunty with default X.org (X Server 1.6.3) and intel driver 2.9.1 (edgers)
 - Jaunty with Kernel 2.6.33rc8 (X Server 1.6.3) and intel driver 2.9.1

[Ts+freedesktop-bugzilla (ts+freedesktop-bugzilla)]

Created an attachment (id=33411)
dmesg output of the ThinkPad R60e

[Ts+freedesktop-bugzilla (ts+freedesktop-bugzilla)]

Created an attachment (id=33412)
Xorg.0.log ThinkPad R60e

[Ts+freedesktop-bugzilla (ts+freedesktop-bugzilla)]

Created an attachment (id=33413)
xrandr --verbose ThinkPad R60e

[Ts+freedesktop-bugzilla (ts+freedesktop-bugzilla)]

(In reply to comment #35)
> Ok, re-opening. Can you capture a register dump from the working and broken
> cases and report which resolutions you had set?

Okay, I can do that with my ThinkPad R60e and a Samsung P2350 connected via VGA. Native resolution of the P2350 is 1920x1080.

[Ts+freedesktop-bugzilla (ts+freedesktop-bugzilla)]

Created an attachment (id=33487)
register dump working resolution 1440x900

[Ts+freedesktop-bugzilla (ts+freedesktop-bugzilla)]

Created an attachment (id=33488)
register dump broken case, resolution is set to 1920x1080

register dump generated while non working resolution was enabled

[Karl Ljungkvist (k-ljungkvist)]

I've done some system changes lately (which did not resolve this issue though). Here is an up-to-date report.

System environment:
-- chipset: 945GM
-- system architecture: 32-bit, i686
-- xf86-video-intel: 2.10.0
-- xserver: 1.7.5.901
-- libdrm: 2.4.18
-- mesa: 7.7
-- intel-dri: 7.7
-- kernel: 2.6.32.9
-- Linux distribution: Arch Linux
-- Machine or mobo model: Compaq Presario V6103EA
-- Display connector: VGA

Reproducing steps:

1. Booted with drm.debug=0x06.
2. startx
3. Plugged in VGA
4. xrandr --output VGA1 --auto --output LVDS1 --off # external in 1920x1080, internal off
  <now in flicker state>
6. xrandr --output VGA1 --off --output LVDS1 --auto # back to only internal in 1280x800

I attach xrandr --verbose output and reg dumps (with intel_reg_dumper) made before and during the flicker state. After switching back, I saved the output of dmesg, and a copy of Xorg.0.log. I also attach my xorg.conf although it's pretty minimal.

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=33852)
Output of xrandr --verbose before switching on the external display.

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=33853)
Output of intel_reg_dumper before switching on the external display.

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=33854)
Output of xrandr --verbose after switching on the external display at 1920x1080.

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=33855)
Output of intel_reg_dumper after switching on the external display at 1920x1080.

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=33856)
dmesg output after switching back to internal display.

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=33857)
Xorg.0.log after switching back to internal display.

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=33858)
xorg.conf used

[Karl Ljungkvist (k-ljungkvist)]

Now this is interesting. I don't know if it was clear already, but the problem occurs already _before_ starting X. When booting up with the external monitor plugged in, the external display duplicates the internal. First everything is fine, but at some point the resolution (of both) is changed (kms?). From this point onward, the external shows the weird flickering. See attached video (sorry for the really bad quality).

[Karl Ljungkvist (k-ljungkvist)]

Video of flickering during boot up can be found here:
http://tinyurl.com/y9vdpum

[Jesse Barnes (jbarnes-virtuousgeek)]

Could be FIFO underruns, Yakui maybe your FIFO patchset fixes this.

[Karl Ljungkvist (k-ljungkvist)]

Can someone comment on the fact that I'm seeing the resolution problem already in the virtual consoles before starting X. What does this mean? Which is the relevant software component (i.e. is this the right one)?

Is more information needed? I'd do anything to get more active help on this issue.

[Jesse Barnes (jbarnes-virtuousgeek)]

I think this should be fixed now; we've made some changes to our FIFO allocations to make things work better.

[Karl Ljungkvist (k-ljungkvist)]

I tried this with the following packages (arch linux)

-- xf86-video-intel: 2.12.0-1
-- xserver: 1.8.1.902-1
-- libdrm: 2.4.21-1
-- mesa: 7.8.2-1
-- intel-dri: 7.8.2-1

in conjunction with kernel versions 2.6.34.1 and 2.6.35rc5 and I am sorry to say that neither gave any improvements. It behaves exactly like described above. Is there anything I can do, or any information I can provide?

[Jesse Barnes (jbarnes-virtuousgeek)]

Arg I was really hoping we had fixed this... Can you load drm with debug=4 and attach the output of dmesg from a fresh boot here? Don't bother starting X, since the problem occurs with a plain console I'd like to avoid all the debug output that X creates.

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=37180)
dmesg output (2.6.34.1 kernel)

Sure.

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=37181)
dmesg output (2.6.35rc5 kernel)

[Jesse Barnes (jbarnes-virtuousgeek)]

Chris reminded me that we don't adjust DSPARB. If this really is a FIFO size problem, this patch may help. It steals all the plane C entries for use in plane B, so it might change things. Please give it a try and attach the debug=4 output again.

Thanks.

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 9ddb7b5..f57f83e 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1434,6 +1434,8 @@ static int i915_load_modeset_init(struct drm_device *dev,

        I915_WRITE(INSTPM, (1 << 5) | (1 << 21));

+ I915_WRITE(DSPARB, (127 << 7) | (28));
+
        ret = intel_fbdev_init(dev);
        if (ret)
                goto cleanup_irq;

[Chris Wilson (ickle)]

The argument centers around:

[drm:intel_update_watermarks], plane B (pipe 0) clock: 138500
[drm:intel_update_watermarks], plane A (pipe 1) clock: 68940
[drm:i9xx_get_fifo_size], FIFO size - (0x00001d9c) A: 28
[drm:i9xx_get_fifo_size], FIFO size - (0x00001d9c) B: 31
[drm:intel_calculate_wm], FIFO entries required for mode: 21
[drm:intel_calculate_wm], FIFO watermark level: 5
[drm:intel_calculate_wm], FIFO entries required for mode: 43
[drm:intel_calculate_wm], FIFO watermark level: -14
[drm:i9xx_update_wm], FIFO watermarks - A: 5, B: 1
[drm:i9xx_update_wm], Setting FIFO watermarks - A: 5, B: 1, C: 2, SR 1

What should be noted here is that by simply using the preset fifo sizes of 28, 31 we cannot accommodate the external display which requires 43 entires [43 >> 31].

As this is a 915 we should have 96 entries to play with, but the advice is not to modify the fifo sizes at runtime, so to test the hypothesis we can try setting the DSPARB to give the maximum bandwidth to external displays at init:

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 9ddb7b5..edaae6c 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1434,6 +1434,13 @@ static int i915_load_modeset_init(struct drm_device *dev,

        I915_WRITE(INSTPM, (1 << 5) | (1 << 21));

+ /* XXX hack for bug 22996, preset the FIFO to accommodate a 2048 external display */
+ {
+ uint32_t size = I915_READ(DSPARB) & 0x7f;
+ size = (95 - size) << DSPARB_CSTART_SHIFT;
+ I915_WRITE(DSPARB, size);
+ }
+
        ret = intel_fbdev_init(dev);
        if (ret)
                goto cleanup_irq;

[Chris Wilson (ickle)]

D'oh, missed Jesse replied! :)

[Jesse Barnes (jbarnes-virtuousgeek)]

Have you had a chance to try one of the patches yet?

[Karl Ljungkvist (k-ljungkvist)]

Okay, I managed to compile the kernel with the patch (I'm proud). I applied it (Chris') to the drm-intel branch of Eric Anholt.

The results are not that good though. The VGA display behaves exactly like before. Now, however, the internal laptop display goes blank at the same moment as the resolution normally changes. When I tried to compile the unpatched branch the problem was gone, so it really has to be due to this patch.

dmesg outputs obtained like above are attached (with and without the external display plugged in respectively).

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=37354)
dmesg output (patched kernel, VGA unplugged)

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=37355)
dmesg output (patched kernel, VGA attached)

[Chris Wilson (ickle)]

(In reply to comment #64)
> Okay, I managed to compile the kernel with the patch (I'm proud). I applied it
> (Chris') to the drm-intel branch of Eric Anholt.
>
> The results are not that good though. The VGA display behaves exactly like
> before. Now, however, the internal laptop display goes blank at the same moment
> as the resolution normally changes. When I tried to compile the unpatched
> branch the problem was gone, so it really has to be due to this patch.

mea culpa.

Can you retry with size |= (95 - size) << DSPARB_CSTART_SHIFT;

Sorry.

[Karl Ljungkvist (k-ljungkvist)]

Now the issue with the internal display is gone. Still no improvement on the VGA though. Note that it showed the same flickering with both the good and the bad patch (and without them). Attaching dmesg.out as always.

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=37356)
dmesg output (patched kernel, VGA attached)

[Chris Wilson (ickle)]

Karl, humour me and put a printk("setting DSPARB to %x\n", size); in the hack as the patch kernel, VGA attached dmesg still only has:

[drm:i9xx_get_fifo_size], FIFO size - (0x0000219c) A: 28
[drm:i9xx_get_fifo_size], FIFO size - (0x0000219c) B: 39

which is what we trying to fix.

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=37357)
dmesg output (patched kernel, VGA attached)

[Chris Wilson (ickle)]

Jesse was right, I am an idiot. Just re-read the description for DSPARB and it is the cumulative value and not the width for the pipe. So:

+ I915_WRITE(DSPARB, (127 << 7) | (I915_READ(DSPARB) & 0x7f));

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=37359)
dmesg output (patch2, VGA attached)

Tried this, but there was no noticeable change. dmesg output attached (still with that printk statement).

[Chris Wilson (ickle)]

Well at least we succeed in generating enough head room for the FIFO.

[drm:intel_update_watermarks], plane B (pipe 0) clock: 138500
[drm:intel_update_watermarks], plane A (pipe 1) clock: 68940
[drm:i9xx_get_fifo_size], FIFO size - (0x00003f9c) A: 28
[drm:i9xx_get_fifo_size], FIFO size - (0x00003f9c) B: 99
[drm:intel_calculate_wm], FIFO entries required for mode: 21
[drm:intel_calculate_wm], FIFO watermark level: 5
[drm:intel_calculate_wm], FIFO entries required for mode: 43
[drm:intel_calculate_wm], FIFO watermark level: 54
[drm:i9xx_update_wm], FIFO watermarks - A: 5, B: 54
[drm:i9xx_update_wm], Setting FIFO watermarks - A: 5, B: 54, C: 2, SR 1

Hah, I wonder if we are now stressing the hardware too much in the other direction.

Tobias, one last test before we look elsewhere:

I915_WRITE(DSPARB, (50 << 7) | 28); /* give's up on all pretence of elegance */

[Chris Wilson (ickle)]

idiot in charge of keyboard again, should be:

I915_WRITE(DSPARB, ((50 + 28) << 7) | 28)

[Karl Ljungkvist (k-ljungkvist)]

Tried the suggested changes. Although the problem is still there, the flickering was somewhat different. I would say that the frequency is lower. To me it has always appeared as if the the problem was that the lines drawn are somewhat too long. It now seems like this difference is smaller. I'll upload a video so you can judge yourselves.

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=37362)
dmesg output (patch3, VGA attached)

[Chris Wilson (ickle)]

Or maybe we are on the right track and underestimating the latency and thus the required FIFO size?

I915_WRITE(DSPARB, (95 << 7) | 28);

Worth a shot.

[Karl Ljungkvist (k-ljungkvist)]

Take a look here:

http://www.youtube.com/watch?v=Y0KDaO3Wl0s

I want to stress that the frequency is not higher than it appears to be on the
video. Compare against the old video:

http://www.youtube.com/watch?v=8JyP_dyVAAE

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=37365)
dmesg output (patch4, VGA attached)

Nope, now it went back to the higher frequency.

[Chris Wilson (ickle)]

Ok, go back to the least broken DSPARB, and try setting various modes on the panel. Start with the lowest resolution and work up, and note when it breaks. I think that will tell us more about the limits we are trying to fix.

[Karl Ljungkvist (k-ljungkvist)]

Okay:

  1920x1080 The slow flickering captured on the video
  1600x1200 Fast flickering as before
  1680x1050 Fast flickering as before
  1280x1024 OK
  1440x900 OK
  1280x960 OK
  1280x800 OK
  1024x768 OK
  800x600 OK
  640x480 OK

[Chris Wilson (ickle)]

Karl, please tell me you have the drm.debug log for that session? :-)

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=37392)
dmesg output when trying out various resolutions (patch3, VGA attached)

Nope. But shell scripting saves the day once again. :)

Here you go. There are lines indicating where each mode was turned on. The screen was also active during the boot up and log in.

[Chris Wilson (ickle)]

Next random patch, this will need to be applied in conjunction with increasing DSPARB:

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 1edaa3f..962405b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2844,7 +2844,7 @@ static void pineview_disable_cxsr(struct drm_device *dev)
  * A value of 5us seems to be a good balance; safe for very low end
  * platforms but not overly aggressive on lower latency configs.
  */
-static const int latency_ns = 5000;
+static const int latency_ns = 9000;

 static int i9xx_get_fifo_size(struct drm_device *dev, int plane)
 {

Karl, as an aside what is your memory configuration? I presume DDR2 (since it is an 945GM). But what speed/latency? Jesse thinks there are some bits in the MCHBAR that can help us, but it will probably need a magic table as well.

[Karl Ljungkvist (k-ljungkvist)]

(In reply to comment #85)
> Next random patch, this will need to be applied in conjunction with increasing
> DSPARB:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_d
> index 1edaa3f..962405b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2844,7 +2844,7 @@ static void pineview_disable_cxsr(struct drm_device *dev)
> * A value of 5us seems to be a good balance; safe for very low end
> * platforms but not overly aggressive on lower latency configs.
> */
> -static const int latency_ns = 5000;
> +static const int latency_ns = 9000;
>
> static int i9xx_get_fifo_size(struct drm_device *dev, int plane)
> {
>
> Karl, as an aside what is your memory configuration? I presume DDR2 (since it
> is an 945GM). But what speed/latency? Jesse thinks there are some bits in the
> MCHBAR that can help us, but it will probably need a magic table as well.

I tried applying this on top of the old working one, but there were no observable difference.

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=37417)
dmesg output when trying out various resolutions ('patch3' & increased latency)

[Karl Ljungkvist (k-ljungkvist)]

(In reply to comment #87)
> Created an attachment (id=37417) [details]
> dmesg output when trying out various resolutions ('patch3' & increased latency)

Have you had any new ideas regarding this?

[Chris Wilson (ickle)]

I have a suspicion (that I'm currently working through) that our WM calculation is off by a factor of 10. That is I believe clock_in_khz is a misnomer as the clock is [elsewhere at least!] being passed around in 10 KHz units,

[cut-n-paste fail so manually typing]
intel_display.c::intel_calculate_wm()
change entries_required to be

entries_required = ((clock_in_khz / 1000) * pixel_size *latency_ns) / 10000;

That is change the final divide to be by ten thousand instead of one thousand.

[Chris Wilson (ickle)]

Created an attachment (id=38008)
Change WM computation

The 10KHz clock was a red-herring. In the LVO dtd it is in 10KHz units, but we only ever use 1KHz for mode clocks.

Looking again at the watermark calculation, it feels backward. The goal is to compute the how many entries will be drained whilst we fetch from memory, not how many entries will be fetched. So the attached patch corrects that.

However, this is likely to be half the problem as we simply do not allocate sufficient FIFO memory to handle the resolution of the pipe (probably ;-). So you may need to try the DSPARB adjustments in conjunction with this patch. Please let me know how this works for you.

[Chris Wilson (ickle)]

Dug out my 915GM and plugged it into my 1920x1080 panel => immediate flicker.
Applied patch, rebuilt world. It works.

\o/ Party!

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=38083)
dmesg output, various resolutions, patch 38008

I cloned git://anongit.freedesktop.org/~ickle/linux-2.6 and after fixing one compilation error and disabling some modules (CONFIG_STAGING=n), I managed to build the drm-testing branch.

By itself this patch did not solve the problem for me. The flickering is sort of the same, and it even introduced a new issue: from resolutions 1024x768 and upward the picture jumps sideways every other second (depends on the activity on the desktop, i.e. if I resize a window, it jumps frantically). This seems to be happening on my internal panel as well, regardless of whether the external is on or off.

Here is a dmesg dump similar to 37392.

I'll try it in conjunction with the other one that improved things.

[Karl Ljungkvist (k-ljungkvist)]

Observations:

  1920x1080 Fast flickering
  1600x1200 Fast flickering
  1680x1050 Fast flickering
  1280x1024 OK, but jumpy
  1440x900 OK, but jumpy
  1280x960 OK, but jumpy
  1280x800 OK, but jumpy
  1024x768 OK, but jumpy
  800x600 OK
  640x480 OK

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=38084)
dmesg output, various resolutions, patch 38008 + DSPARB fix

Tried to add this again:

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 2110ad8..7b96981 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1438,6 +1438,8 @@ static int i915_load_modeset_init(struct drm_device *dev,
        /* FIXME: do pre/post-mode set stuff in core KMS code */
        dev->vblank_disable_allowed = 1;

+ I915_WRITE(DSPARB, ((50 + 28) << 7) | 28);
+
        ret = intel_fbdev_init(dev);
        if (ret)
                goto cleanup_irq;

Results are:
* The flickering on 1920x1080 is slower again
* The jumpiness is gone on the external, now it only happens on the internal display, at the same modes as above.

The usual dmesg output attached.

[Chris Wilson (ickle)]

I think we're winning! Aside from that you also suffer from the spurious TV detection, which drives the system nuts later on, I think we're underestimating the FIFO space required. Even the 50 for the external display is too little for 1680x1050 and up [as reported in dmesg].

Let's bump up the amount of memory allocated to each pipe:

  I915_WRITE(DSPARB, ((80 + 40) << 7) | 40);

and be more pessimistic in our latency:

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index a0a8457..d020823 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2858,7 +2858,7 @@ static void pineview_disable_cxsr(struct drm_device *dev)
  * A value of 5us seems to be a good balance; safe for very low end
  * platforms but not overly aggressive on lower latency configs.
  */
-static const int latency_ns = 5000;
+static const int latency_ns = 7000;

 static int i9xx_get_fifo_size(struct drm_device *dev, int plane)
 {

Karl, do you have any clues as to what memory you have in your system? In our table of know configurations on PineView, latency ranges from 3300 (DDR2-400) to 6500 (DDR3-667). In constrast Ironlake latency is 700!

[Karl Ljungkvist (k-ljungkvist)]

Now this is very interesting. At the moment I have access to a 22" display with maximum resolution 1680x1050. I tried plugging it in, and believe it or not, but it works using the standard 2.6.35.3 kernel! I don't know what this means, but it definitely seems weird that 1680x1050 works on one monitor but not on another.

Once I get home I'll try out the new edits (and check the memory configuration, need a screwdriver for that).

[Chris Wilson (ickle)]

(In reply to comment #96)
> Now this is very interesting. At the moment I have access to a 22" display with
> maximum resolution 1680x1050. I tried plugging it in, and believe it or not,
> but it works using the standard 2.6.35.3 kernel! I don't know what this means,
> but it definitely seems weird that 1680x1050 works on one monitor but not on
> another.

Would be worth having a look at the differences in dmesg [and xrandr --verbose]. The critical factor in the calculations is the pixel clock [mode clock], it may just be that for one monitor due to hblank/vblank the pixel clock is much higher.

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=38100)
dmesg output, 22", 2.6.25.3, up to console login

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=38101)
xrandr output, 22", 2.6.25.3

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=38102)
dmesg output, 23", 2.6.25.3, up to console login

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=38103)
xrandr output, 23", 2.6.25.3

[Karl Ljungkvist (k-ljungkvist)]

(In reply to comment #95)
> Karl, do you have any clues as to what memory you have in your system? In our
> table of know configurations on PineView, latency ranges from 3300 (DDR2-400)
> to 6500 (DDR3-667). In constrast Ironlake latency is 700!

The RAM memory chip says PC2-5300 which I think means 667MHz, but dmidecode reports 533 MHz.

[Karl Ljungkvist (k-ljungkvist)]

(In reply to comment #95)
> Let's bump up the amount of memory allocated to each pipe:
>
> I915_WRITE(DSPARB, ((80 + 40) << 7) | 40);
>
> and be more pessimistic in our latency:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> ...

Tried this, applied to drm-testing (2450f47494ed63ac32053b7bdf12088bc504cef6). Still no success though. The difference since last time was that the flickering at 1920x1080 was now very fast again. dmesg output follows.

[Karl Ljungkvist (k-ljungkvist)]

Created an attachment (id=38104)
dmesg output, various resolutions, patch 38008, DSPARB fix #2, latency increase

[Jesse Barnes (jbarnes-virtuousgeek)]

Looks like 16x10 on the 23" panel uses a higher dotclock; it's not a reduced blanking mode:

good:
  1680x1050 (0x44) 119.0MHz +HSync -VSync *current +preferred
        h: width 1680 start 1728 end 1760 total 1840 skew 0 clock 64.7KHz
        v: height 1050 start 1053 end 1059 total 1080 clock 59.9Hz

bad:
  1680x1050 (0xb6) 146.2MHz -HSync +VSync
        h: width 1680 start 1784 end 1960 total 2240 skew 0 clock 65.3KHz
        v: height 1050 start 1053 end 1059 total 1089 clock 60.0Hz

The 1920x1080 resolution on the 23" looks like it's reduced though:

  1920x1080 (0xb4) 138.5MHz +HSync -VSync +preferred
        h: width 1920 start 1968 end 2000 total 2080 skew 0 clock 66.6KHz
        v: height 1080 start 1083 end 1088 total 1111 clock 59.9Hz

I wonder if the Windows driver squeezes the htotal/vtotal down even further though, reducing the pixel clock requirements a bit more...

If you want to run 16x10 on the 23", you could try adding a custom mode using the output of cvt -r 1680 1050, and using that in your config instead of the EDID provided mode.

[Karl Ljungkvist (k-ljungkvist)]

(In reply to comment #105)

> If you want to run 16x10 on the 23", you could try adding a custom mode using
> the output of cvt -r 1680 1050, and using that in your config instead of the
> EDID provided mode.

Yes, that did work! The image was a little bit blurry, or should I say 'uncrisp', but no flickering at all.

[Jesse Barnes (jbarnes-virtuousgeek)]

I assume it's just as blurry under Windows? Did you want to run the panel at 19x12 or is 16x10 what you were aiming for?

[Karl Ljungkvist (k-ljungkvist)]

(In reply to comment #107)
> I assume it's just as blurry under Windows? Did you want to run the panel at
> 19x12 or is 16x10 what you were aiming for?

Right. The blurriness is there on windows too, and of course it's just aliasing effects from the supersampling. Anyways, it is the 1920x1080 I want to use since that is the native resolution of the display.

[Jesse Barnes (jbarnes-virtuousgeek)]

Can you somehow get the timings of the modes used under Windows? And ideally a register dump of the MMIO region of the gfx device?

[Karl Ljungkvist (k-ljungkvist)]

(In reply to comment #109)
> Can you somehow get the timings of the modes used under Windows? And ideally a
> register dump of the MMIO region of the gfx device?

Wow, that's a bit out of my field. Would you mind giving me some help on how I would go about doing that?

[Jesse Barnes (jbarnes-virtuousgeek)]

Looks like a tool like http://www.pcitree.de/userguide.html#BARspace would be able to dump the BAR space of the gfx device, then we could compare what Windows does with what we do (assuming you still have this problem and you haven't given up hope on this 2 year old bug).

[Laszlo_Lebrun (lazlo-lebrun)]

I have got following config: a notebook with GMA950 running Ubuntu 11.04 and an external monitor with 1920x1080 resolution connected over VGA.
With the previous version 10.10 I could run both screens flawlessly.

With Ubuntu 11.04 running dual screen produces a lot of artifacts, running on internal flat panel is OK.
Upon moving a window, the trail is not cleared; the background disapears, unity fails to return the dock.

The artifacts come with Gnome and Unity equally.

I suppose Compiz is the culprit...

[Michel.Firholz (michel-firholz-vr-web)]

I can confirm: without effects GMA 950 runs perfectly two HD monitors. With Compiz, only one.
I just stay without Compiz... and in consequence without Unity.

[Pde-u (pde-u)]

I have been suffering from blurry VGA output on my Thinkpad T410s under Debian. For me this occurs even at lower resolutions (800x600 @ 60 Hz, say). It is Extremely Frustrating. Is there anything I can do to help get a fix implemented?

[Chris Wilson (ickle)]

Mass status change to NEEDINFO based on presence of NEEDINFO keyword. Please reopen if you can still reproduce the bug and are able to provide the information requested, thanks.

[Chris Wilson (ickle)]

Timeout. Please do reopen if you can still reproduce the issue and help us diagnose the problem, thanks.