[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.

[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.