Bug 9963 - Part of screen corrupt with EXA enabled
Summary: Part of screen corrupt with EXA enabled
Status: RESOLVED DUPLICATE of bug 9576
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Acceleration/EXA (show other bugs)
Version: 7.1 (2006.05)
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-13 00:15 UTC by Thomas Wolfe
Modified: 2007-02-13 05:52 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments
screenshot (386.89 KB, image/png)
2007-02-13 00:16 UTC, Thomas Wolfe 		no flags Details
xorg configuration (4.68 KB, text/plain)
2007-02-13 00:16 UTC, Thomas Wolfe 		no flags Details
Xorg log (47.98 KB, text/plain)
2007-02-13 00:17 UTC, Thomas Wolfe 		no flags Details
View All

Description Thomas Wolfe 2007-02-13 00:15:31 UTC 
Only happens with beryl or compiz, metacity it is fine.  When I only change to EXA from XAA and nothing else, I get corruption, a white background, the right half of the screen gets garbled, and the taskbar does not display in gnome.
attaching org.0.log, xorg.conf, and a screenshot.
This is on a T41 thinkpad with a radeon 9000 mobility chip.
Comment 1 Thomas Wolfe 2007-02-13 00:16:11 UTC 
Created attachment 8695 [details]
screenshot

screenshot when i switch to beryl
Comment 2 Thomas Wolfe 2007-02-13 00:16:57 UTC 
Created attachment 8696 [details]
xorg configuration
Comment 3 Thomas Wolfe 2007-02-13 00:17:29 UTC 
Created attachment 8697 [details]
Xorg log
Comment 4 Michel Dänzer 2007-02-13 00:45:32 UTC 
See bug 9576 and bug 9223.
Comment 5 Thomas Wolfe 2007-02-13 03:05:55 UTC 
well, I am running at 16 bit as you can see from the configuration, and still problems, so is it the same bug?
Comment 6 Thomas Wolfe 2007-02-13 03:13:00 UTC 
forgot to mention, setting up /etc/drirc as in bug 9223 does nothing, still the same problem...
Comment 7 Michel Dänzer 2007-02-13 03:56:38 UTC 
It doesn't depend on the depth directly but on the amount of video RAM reserved for textures.

What does

glxinfo -i -l | grep MAX_TEXTURE_SIZE

say?
Comment 8 Thomas Wolfe 2007-02-13 04:45:31 UTC 
It says:

GL_MAX_TEXTURE_SIZE = 1024

so, just curious, what does that mean?  going to go out on a limb and guess it means I have to run at 1024x768 resolution, although I am not sure...
Comment 9 Michel Dänzer 2007-02-13 05:04:55 UTC 
Yeah, it means the 3D driver doesn't support textures larger than 1024x1024, so it's the same problem as in the other bug reports I mentioned.

The question is why the /etc/drirc parameter doesn't work... Did you change the driver from "radeon" to "r200" and restart the X server afterwards?
Comment 10 Thomas Wolfe 2007-02-13 05:36:18 UTC 
No, but just now I did change the driver to r200
<driconf>
    <device screen="0" driver="r200">
        <application name="all">
            <option name="allow_large_textures" value="2" />
        </application>
    </device>
</driconf>

did a quick ctrl-alt-backspace logged in again, and still stuck with 1024 textures...
xorg.conf and stuff is still the same as what I posted here...
Comment 11 Thomas Wolfe 2007-02-13 05:52:33 UTC 
well, it is working fine and dandy now, turns out driconf created a ~/.drirc file, so just needed to enable large textures in driconf and delete the /etc/drirc file.

Curious why large textures are by default not enabled, does it cause some apps to break or behave strangely?
closing this bug, sorry to bother and thanks for the help.

*** This bug has been marked as a duplicate of bug 9576 ***

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.