|
Description
Bryce Harrington
2009-07-27 22:47:05 UTC
Created attachment 28110 [details]
This happens on the screen screen.jpg
Created attachment 28111 [details]
xorg log just BEFORE my ext. monitor was connected
Created attachment 28112 [details]
xorg after the monitor was configured to high res.
Created attachment 28113 [details]
I was trying to do this. It printed no errors after applying changes.
need a xorg.log, with option "modedebug" "true" set in xorg.conf.. Created attachment 28126 [details]
xorg.log with modedebug Ubuntu 9.04
xorg.log provided
Created attachment 28127 [details]
xorg.log with modedebug Ubuntu 9.10 Alpha 3
previous xorg.log was from Ubuntu 9.04
this one is from Ubuntu 9.10 Alpha 3 with the same config file.
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.
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). Created attachment 28170 [details]
xorg.conf with only ext. monitor on
Created attachment 28171 [details]
Xorg.0.log with only ext. monitor on
from the regdump, it looks like fifo issue... 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) (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. Created attachment 28226 [details] 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. (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. Created attachment 28380 [details]
xorg.log - Option "FrameBufferCompression" "False"
No change, it didn't fix it.
see if Jesse has any idea... If it's FIFO related, it should either be fixed by recent kernel bits or by the patch in bug #22921. Can you test? 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. Assuming this one is fixed by the recent FIFO updates to the kernel. 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 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? Created attachment 30704 [details]
video of the bug
I just tried it without compiz and only on 1 monitor. Still the same bug.
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 Created attachment 30707 [details] [review] Lines added to Xorg.0.log When running the said commands these are the lines added to Xorg.0.log. Created attachment 30708 [details]
Output of xrandr -q
...and this is the output produced by xrandr -q when the external monitor is plugged in.
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. (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. Maybe this was fixed by this kernel commit? commit 629598da932cfa5ff398fe10bc123282a6f3049e Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Oct 20 07:37:32 2009 +0900 drm/i915: update watermarks before enabling PLLs (In reply to comment #30) > Maybe this was fixed by this kernel commit? > > commit 629598da932cfa5ff398fe10bc123282a6f3049e > Author: Jesse Barnes <jbarnes@virtuousgeek.org> > 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? 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. 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). (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 Ok, re-opening. Can you capture a register dump from the working and broken cases and report which resolutions you had set? 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 Created attachment 33411 [details]
dmesg output of the ThinkPad R60e
Created attachment 33412 [details]
Xorg.0.log ThinkPad R60e
Created attachment 33413 [details]
xrandr --verbose ThinkPad R60e
(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. Created attachment 33487 [details]
register dump working resolution 1440x900
Created attachment 33488 [details]
register dump broken case, resolution is set to 1920x1080
register dump generated while non working resolution was enabled
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. Created attachment 33852 [details]
Output of xrandr --verbose before switching on the external display.
Created attachment 33853 [details]
Output of intel_reg_dumper before switching on the external display.
Created attachment 33854 [details]
Output of xrandr --verbose after switching on the external display at 1920x1080.
Created attachment 33855 [details]
Output of intel_reg_dumper after switching on the external display at 1920x1080.
Created attachment 33856 [details]
dmesg output after switching back to internal display.
Created attachment 33857 [details]
Xorg.0.log after switching back to internal display.
Created attachment 33858 [details]
xorg.conf used
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). Video of flickering during boot up can be found here: http://tinyurl.com/y9vdpum Could be FIFO underruns, Yakui maybe your FIFO patchset fixes this. 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. I think this should be fixed now; we've made some changes to our FIFO allocations to make things work better. 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? 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. Created attachment 37180 [details]
dmesg output (2.6.34.1 kernel)
Sure.
Created attachment 37181 [details]
dmesg output (2.6.35rc5 kernel)
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;
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;
D'oh, missed Jesse replied! :) Have you had a chance to try one of the patches yet? 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). Created attachment 37354 [details]
dmesg output (patched kernel, VGA unplugged)
Created attachment 37355 [details]
dmesg output (patched kernel, VGA attached)
(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. 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. Created attachment 37356 [details]
dmesg output (patched kernel, VGA attached)
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.
Created attachment 37357 [details]
dmesg output (patched kernel, VGA attached)
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)); Created attachment 37359 [details]
dmesg output (patch2, VGA attached)
Tried this, but there was no noticeable change. dmesg output attached (still with that printk statement).
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 */ idiot in charge of keyboard again, should be: I915_WRITE(DSPARB, ((50 + 28) << 7) | 28) 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. Created attachment 37362 [details]
dmesg output (patch3, VGA attached)
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. 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 Created attachment 37365 [details]
dmesg output (patch4, VGA attached)
Nope, now it went back to the higher frequency.
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. 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 Karl, please tell me you have the drm.debug log for that session? :-) Created attachment 37392 [details]
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.
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.
(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. Created attachment 37417 [details]
dmesg output when trying out various resolutions ('patch3' & increased latency)
(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? 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. Created attachment 38008 [details] [review] 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. Dug out my 915GM and plugged it into my 1920x1080 panel => immediate flicker. Applied patch, rebuilt world. It works. \o/ Party! Created attachment 38083 [details]
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.
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 Created attachment 38084 [details]
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.
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!
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). (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. Created attachment 38100 [details]
dmesg output, 22", 2.6.25.3, up to console login
Created attachment 38101 [details]
xrandr output, 22", 2.6.25.3
Created attachment 38102 [details]
dmesg output, 23", 2.6.25.3, up to console login
Created attachment 38103 [details]
xrandr output, 23", 2.6.25.3
(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. (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. Created attachment 38104 [details]
dmesg output, various resolutions, patch 38008, DSPARB fix #2, latency increase
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.
(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. 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? (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. 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? (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? 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). 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? 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. Timeout. Please do reopen if you can still reproduce the issue and help us diagnose the problem, thanks. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.