Hi. I have an i945 chipset and it seems that whenever I play a native Linux game like World of Goo or a Wine-powered game Touhou in fullscreen, I experience a rather strange problem. The game will trigger a switch to fullscreeen, but almost the entire left half of the screen gives funky bands of color while the right side appears mostly normal. Furthermore, sometimes the left of the screen will look relatively fine, but there will be a visible dividing line between the two halves of the screen. Also, for either scenario, the entire screen will appear speckled. Finally, it is important that I also point out that I if use an external LCD monitor or TV in standalone or clone mode, the problem will not appear on that other screen. Thanks in advance. - Eric
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)
Created attachment 24383 [details] lspci output
Created attachment 24384 [details] Xorg.0.log output
Created attachment 24385 [details] xrandr verbose output
Could you provide more info about your driver version? If it's shipped from distro, what's the detailed distro version? And what's previous version which worked for you?
Driver: xserver-xorg-video-intel - 2:2.6.99.1+git20090327.69c84f2c-0ubuntu0tormod Also, I am using Ubuntu 9.04. I can't clearly remember the last version that worked for me, but if I had to hazard a safe guess, I'd say definitely Ubuntu 8.04 and possibly even Ubuntu 8.10. I'll have to do a LiveUSB test to double-check.
BTW, just in case I was vague. Driver versions 8.04: 2.2.2 8.10: 2.4.1 I'm quite confident that the 2.5.x driver series introduced the error, but as I mentioned, I'll have to check.
Let's sync the reproduce method first. Eric, could you reproduce with some other native Linux games like openarena, ut2004-demo, quake3-demo or torcs. It's easier for us to test them, and in my impression they don't have this problem with upstream driver.
Confirming that the problem is present in fresh LiveUSB sessions of Ubuntu 9.04, but not Ubuntu 8.10. In OpenArena, the corruption was present in all resolutions except for 1360x768 where the screen rendered everything rather normally aside from a flashing black box that occasionally appeared. I imagine that if the game had a native 1440x900 resolution mode, it would render similarly, if not perfectly.
Haien, do you see this problem with openarena with 2.7 branch on 945gm?
(In reply to comment #10) > Haien, do you see this problem with openarena with 2.7 branch on 945gm? I just played openarena with 2.7 branch on 945gm, it works well.
I'm pretty convinced that this is a modeline issue. Also, zhao, define "it works well". As far as I am concerned the i945gm chipset running on 2.7.x drivers is still plagued by a17 tiling issues that lead to a ~6x performance loss compared to the 2.4.x series drivers.
Created attachment 24430 [details] please try the debug patch on your machine, thanks.
The patch is useless since the DRM and intel git break my system. If you can debian package libdrm 2.4.6 and a patched intel driver for me, I'll be able to test.
Created attachment 24446 [details] Camera phone images of graphical corruption
(In reply to comment #14) > The patch is useless since the DRM and intel git break my system. Is there a bug filed for this? I'll consider this bug is blocked by that bug.
I wouldn't bother. I probably just need to clean up my 2.6.29 and 2.6.28 headers. Give me a day or two. :3
Okay. I got my machine working with the git drivers and applied the patch. There is no change in the fullscreen behavior.
(In reply to comment #18) > Okay. I got my machine working with the git drivers and applied the patch. > > There is no change in the fullscreen behavior. > we can not reproduce this issue on our 945gm.what is the version of your openarena? could you give me the config file of the game?
Fist of all, have the pictures helped you guys at all? Also, I'd like to reiterate that this issue occurs on practically all non-native modelines and I have repeatedly reproduced this on clean Jaunty live sessions with my laptop. Let me upload a few more Xorg.0.log files that better reflect my system before and after the patch.
FYI. I'm using the latest version of OpenArena, 0.8.1. I have no idea what you are talking about with regard to a config file.
Created attachment 24482 [details] Unpatched Xorg.0.log
Created attachment 24483 [details] Patched Xorg.0.log
Because the game can not triger fullscreen in our machine, and we have to do it manually, but failed to reproduce it. So we hope to use your config file of this game, could you please upload it, and what's your game version? Thanks Ma Ling
(In reply to comment #21) > FYI. I'm using the latest version of OpenArena, 0.8.1. > > I have no idea what you are talking about with regard to a config file. > maybe you can find it in the directory /root/.openarena/baseoa the name is q3config.cfg, upload it if you find. thanks.
Created attachment 24487 [details] Config of default OpenArena settings
>Because the game can not triger fullscreen in our machine, and we have to do it >manually, but failed to reproduce it. So we hope to use your config file of >this game, could you please upload it, and what's your game version? This bug has nothing to do with OpenArena. But in case it means anything, the game fullscreens with the default config.
So... Any ideas?
(In reply to comment #28) > So... Any ideas? > sorry,we still cann't reproduce this issue,could you retry it using the latest driver? Libdrm: (master)51d6346f9f3c425f49e57d185530c6bcaeb94f5e Mesa: (mesa_7_4_branch)de197cf991416f0cd65ad2e2d2ca9aa599b52075 Xserver: (server-1.6-branch)60c161545af80eb78eb790a05bde79409dfdf16e Xf86_video_intel: (2.7)10b5014c42dc055d9559ee112cc7a017e887d813 Kernel: (drm-intel-2.6.29)0e56a4d653b66d4729f944b23935a00c4472f987 thanks.
This sounds a lot like the bug we had awhile ago when non-native modes were added to the LVDS output, but apparently even centered panel fitting doesn't help in this case. I don't see the modeline being used for the game though, has that been checked for validity? Maybe one of the modes we add to the LVDS output isn't correct for this machine? But now that I look, the pictures don't really seem like modeline issues, they seem like rendering problems. This is an UXA/DRI2 configuration, so we don't need to do any sarea updates for resolution changes, but maybe something else is missing? Eric what version of Mesa are you running? I also see that tiling is disabled in this config: (EE) intel(0): Failed to set tiling on front buffer: rejected by kernel Which may also be related (though the pictures don't really look like tiled rendering problems).
Mesa: 7.4 branch (Jaunty) *can also be replicated on 7.3 branch as far as I can remember* Intel: Master or xorg-edgers PPA (usually less than 10 commits apart) DRM: Master or xorg-edgers PPA (usually less than 10 commits apart)
And yes, at the discretion of many, I have GEM/tiling disabled.
Finally, this is not limited to UXA and DRI2, EXA and DRI1 are also affected.
Created attachment 24650 [details] Xorg.0.log output with tiling enabled and without UXA
Is there any other hard data that you guys need?
if you have tried Option "Tiling" "False", how about Option "FrameBufferCompression" "False"
Unfortunately, that didn't help. Also, must I reiterate that the regression window for this bug is between 2.4.1 and current Intel.
Just taking a shot in the dark, but could this be a dithering problem?
Does a dusty or speckled rendering ring any bells either?
Created attachment 24753 [details] glxinfo verbose
Created attachment 24759 [details] Picture of bug symptoms, as seen at the World of Goo title screen
Eric narrowed this down (thanks a ton Eric) to the panel fitting change I pushed awhile back: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=667923559219429b0c5fec12a0164f7eba1f8f2d Which means either the panel fitting regs are broken on his machine or we're getting the timings slightly wrong. Can you take a look at the register dump that Eric will attach, Ma Ling? If this hw truly is broken (i.e. the regs look correct but there's still corruption) we may have to quirk it.
Created attachment 24774 [details] Regdump of corruption while running Touhou 06 in Wine
Created attachment 24775 [details] Regdump of corruption while running OpenArena 0.8.1 natively
Workaround. xrandr --output LVDS --set PANEL_FITTING full
*sigh* It looks like Jaunty will be shipping with this bug unresolved. Hopefully the pending fix will be backported or offered as an update.
Created attachment 25589 [details] please try the patch on your machine, thanks. I checked dump register file in comments #43 and #44, they use resolution 1152x864 and lvds fixed mode is 1440x900,no any incorrect. The patch intends to make quirk for the platform, fore it to use FULL pannel fitting, instead of original FULL_ASPECT. please try it on your machine. Thanks Ma Ling
Ma Ling, I appreciate the patch and it does what you say it does, but I do not consider it to be an acceptable solution to my problem. My native 640x480 games are still stretched and I can't play them like this since they require pixel-level precision. In short, I need FULL_ASPECT.
Created attachment 25612 [details] [review] pfit debugging We can use this to check whether the pfit ratios are sane. Can you apply it and reproduce the corruption, then attach your log?
Created attachment 25616 [details] [review] pfit debugging 2 Actually, try this one. It'll give us more info that should allow us to track down the problem if it's related to bad timing (which I suspect).
(In reply to comment #50) > Created an attachment (id=25616) [details] > pfit debugging 2 > Actually, try this one. It'll give us more info that should allow us to track > down the problem if it's related to bad timing (which I suspect). Eric, when you using this patch, could you please upload log file with modedebug optoin on ? thanks Ma Ling
Created attachment 25647 [details] Xorg.0.log debug output
Created attachment 25648 [details] [review] pfit debugging 3 The ErrorFs I added aren't in your log. This patch makes them into more normal driver error messages. If we still don't see them with this patch applied while you're seeing the corruption, then either you're not running the patched driver or the game you're running isn't going through this path to set the mode...
Created attachment 25649 [details] (World of Goo) Xorg.0.log debug
Created attachment 25650 [details] (Touhou Youyoumu) Xorg.0.log debug
Created attachment 25651 [details] (World of Goo) Xorg.0.log debug
Created attachment 25652 [details] (Touhou Youyoumu) Xorg.0.log debug
Created attachment 25654 [details] [review] potential fix If your panel is in dual-channel mode, this patch might fix things by making the panel fit timings even instead of odd.
That patch helps a lot. The left side corruption is gone. However, the overall "fuzziness" and thin vertical line of corruption down the center of screen are still present.
Can you post a screenshot of the new corruption?
Created attachment 25677 [details] (Touhou Eiyashou) Xorg.0.log debug
I'm also starting to notice faint shadows of previously rendered objects (ie. Touhou seen in World of Goo)
Created attachment 25732 [details] [review] potential fix #2 In some cases the sync range wouldn't fall inside the blank range with the last patch. This one should fix that case. Can you try it out and attach the log again if it fails?
Created attachment 25768 [details] (Touhou Fuujinroku) Xorg.0.log debug (Ignore HAL errors)
No visible improvement with newest patch.
Ling should be coming online soon. Any ideas on the "middle line corruption" part of this, Ling? Sounds like my patch is at least a partial fix (though it needs a little cleanup, I'd appreciate your review; feel free to push it today too if you like it). The 945 chips have a sub-pixel rendering option for panel fitting, maybe that's off in this configuration somehow? Or our scaling calculation results in an odd pixel count for the scaled width?
Created attachment 25781 [details] New photos of corruption New photos of vertical corruption line at dead center of screen. Aforementioned fuzziness is not visible in these photos. Games used: World of Goo, Touhou Koumakyou, and Touhou Youyoumu.
Created attachment 25820 [details] hi Eric, please try the debug patch on your machine under the same environment with comments #61. thanks
Created attachment 25831 [details] (Touhou Eiyashou) Xorg.0.log debug (Ignore tiling errors) Ma Ling, unfortunately your patch seemed to have no noticeable effect. Everything looks the same as an unpatched driver. - Blurry and fuzzy rendering remains - Left-side corruption has returned - Line of corruption down center of screen blends with left-side corruption
Are the current patches going to be added to the git?
Eric, does CENTER mode works when you play those games?
It works, but it's also affected by this bug.
Will you please attach the output of vbios dump? >echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom > cat /sys/devices/pci0000:00/0000:00:02.0/rom > vbios.dump Thanks.
Created attachment 26552 [details] VBIOS dump 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)
Created attachment 26617 [details] [review] Don't change the hsync/vsync while doing LVdS scaling
Will you please try the debug patch and see whether the issue still exists? Thanks.
Created attachment 26632 [details] [review] Don't change the hsync/vsync width while doing LVDS scaling Will you please try the updated patch ? Thanks.
Created attachment 26633 [details] [review] Don't change the hsync/vsync width while doing LVDS scaling Sorry that the incorrect patch is attached. Will you please try the updated debug patch and see whether the issue still exists? Thanks.
Created attachment 26635 [details] Touhou Youyoumu with patch The fuzziness and corruption are gone, but the dividing line between the two halves of the screen is still present. At least we're making progress. ^_^
Created attachment 26657 [details] [review] Don't change the hsync/vsync width while doing LVDS scaling Will you please try the updated patch and see whether the issue still exists? In this debug patch the hsync/vsync width is not changed. And the blank width is printed. After the test, please attach the Xorg log. Thanks.
Created attachment 26689 [details] Xorg.0.log output Patch works. All symptoms of the issue are gone. Will this bug be committed in time for 2.8?
Thanks for the test and so quick response. Will you please try the center scaling mode and see whether it still works for you? After the test, please also attach the Xorg log. Thanks.
Created attachment 26698 [details] [review] don't change the blank/sync width while doing LVDS scaling mode Will you please try the updated patch? Thanks.
Created attachment 26739 [details] Xorg.0.log output for Touhou Fuujinroku Center and full-aspect scaling work properly.
Thanks for the test. I will send the patch to intel-gfx mailing list ASAP. As the bug can be fixed by the attached patch, the bug will be marked as "resolved". Thanks.
Damn. Why didn't I see your message before I submitted the patch to the mailing list myself. Sorry.
commit 534e73ad4f234a04755917f2bf17ba821c27eb52 Author: Zhao Yakui <yakui.zhao@intel.com> Date: Thu Jun 18 09:46:32 2009 +0800 Don't change the blank/sync width when calculating scaled modes
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.