[i945] Fullscreen graphical corruption on laptops with Intel graphics?

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)

Created an attachment (id=24383)
lspci output

Created an attachment (id=24384)
Xorg.0.log output

Created an attachment (id=24385)
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 an attachment (id=24430)
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 an attachment (id=24446)
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 an attachment (id=24482)
Unpatched Xorg.0.log

Created an attachment (id=24483)
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 an attachment (id=24487)
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 an attachment (id=24650)
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 an attachment (id=24753)
glxinfo verbose

Created an attachment (id=24759)
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 an attachment (id=24774)
Regdump of corruption while running Touhou 06

Created an attachment (id=24775)
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 an attachment (id=25589)
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 an attachment (id=25612)
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 an attachment (id=25616)
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 an attachment (id=25647)
Xorg.0.log debug output

Created an attachment (id=25648)
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 an attachment (id=25649)
(World of Goo) Xorg.0.log debug

Created an attachment (id=25650)
(Touhou Youyoumu) Xorg.0.log debug

Created an attachment (id=25651)
(World of Goo) Xorg.0.log debug

Created an attachment (id=25652)
(Touhou Youyoumu) Xorg.0.log debug

Created an attachment (id=25654)
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 an attachment (id=25677)
(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 an attachment (id=25732)
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 an attachment (id=25768)
(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 an attachment (id=25781)
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 an attachment (id=25820)
hi Eric, please try the debug patch on your machine under the same environment with comments #61. thanks

Created an attachment (id=25831)
 (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 an attachment (id=26552)
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 an attachment (id=26617)
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 an attachment (id=26632)
Don't change the hsync/vsync width while doing LVDS scaling

Will you please try the updated patch ?
Thanks.

Created an attachment (id=26633)
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 an attachment (id=26635)
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 an attachment (id=26657)
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 an attachment (id=26689)
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 an attachment (id=26698)
don't change the blank/sync width while doing LVDS scaling mode

Will you please try the updated patch?
Thanks.

Created an attachment (id=26739)
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 <email address hidden>
Date: Thu Jun 18 09:46:32 2009 +0800

    Don't change the blank/sync width when calculating scaled modes