Bug 25397

Summary: Glyphs appear as blocks or distorted on EXA only
Product: xorg Reporter: Simon Thum <simon.thum>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED DUPLICATE QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: medium    
Version: git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
screenshot
none
xorg.log none

Description Simon Thum 2009-12-02 09:24:30 UTC
On my Radeon RV350 IGP and kernel 2.6.31.6, glyphs are rendered as solid blocks under EXA.

Every glyph is rendered as a solid in  the colour they glyph should take for Qt apps, in firefox things get even worse (see screenshot).

I don't use KMS, xorg is from today. Switching to XAA fixes the issue. My other system running pretty much the same setup but with an r200 pci card runs fine so far under EXA, so it might be card specific:

01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] (prog-if 00 [VGA controller])                                                            
        Subsystem: Fujitsu Technology Solutions Device 1080                              
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11                      
        Memory at d0000000 (32-bit, prefetchable) [size=128M]                            
        I/O ports at b000 [size=256]                                                     
        Memory at ffcf0000 (32-bit, non-prefetchable) [size=64K]                         
        Expansion ROM at ffcc0000 [disabled] [size=128K]                                 
        Capabilities: [58] AGP version 2.0                                               
        Capabilities: [50] Power Management version 2                                    
        Kernel driver in use: radeonfb
Comment 1 Simon Thum 2009-12-02 09:25:29 UTC
Created attachment 31664 [details]
screenshot
Comment 2 Simon Thum 2009-12-02 09:35:18 UTC
since a similar bug had to to with aperture size mismatch, here's a kernekl excerpt:

pci 0000:01:00.0: Boot video device
Real Time Clock Driver v1.12b
Non-volatile memory driver v1.3
Linux agpgart interface v0.103
agpgart-intel 0000:00:00.0: Intel 855PM Chipset
agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xe0000000
Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds).
Hangcheck: Using get_cycles().
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
radeonfb 0000:01:00.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
radeonfb: Retrieved PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=6) Memory=250.00 Mhz, System=200.00 MHz
radeonfb: PLL min 20000 max 40000
Non-DDC laptop panel detected
Switched to high resolution mode on CPU 0
i2c-adapter i2c-2: unable to read EDID block.
i2c-adapter i2c-2: unable to read EDID block.
i2c-adapter i2c-2: unable to read EDID block.
radeonfb: Monitor 1 type LCD found
radeonfb: Monitor 2 type no found
radeonfb: panel ID string: Samsung LTN154X1 WXGA
radeonfb: detected LVDS panel size from BIOS: 1280x800
radeondb: BIOS provided dividers will be used
radeonfb: Dynamic Clock Power Management enabled
Console: switching to colour frame buffer device 160x50
radeonfb (0000:01:00.0): ATI Radeon 4e52 "NR"


note the lsci had:
Memory at d0000000 (32-bit, prefetchable) [size=128M]

Comment 3 Simon Thum 2009-12-02 09:37:47 UTC
Created attachment 31665 [details] [review]
xorg.log

log is from an EXA run.
Comment 4 Alex Deucher 2009-12-02 09:39:49 UTC
what xserver are you using?  There were some recent exa breakages in git that resulted in this kind of corruption.  The fix is on the xorg mailing list.  Also mixing radeonfb and X is usually a recipe for problems.
Comment 5 Simon Thum 2009-12-02 13:20:05 UTC
(In reply to comment #4)
> what xserver are you using?  There were some recent exa breakages in git that
today's git pixman, server, driver
> resulted in this kind of corruption.  The fix is on the xorg mailing list. 
Didn't try it yet.
> Also mixing radeonfb and X is usually a recipe for problems.
Then I guess I never had them :)

To check back I updated my desktop, which is pretty much the same software-wise but has an r280 on agp, and it's all fine. Sure, that's not a proof, but it backs the chip-specific hypothesis.
Comment 6 Alex Deucher 2009-12-02 13:40:41 UTC
does this exa patch help?
http://lists.freedesktop.org/archives/xorg-devel/2009-December/003818.html
Comment 7 Simon Thum 2009-12-02 13:58:36 UTC
OK, scrap the chip specific theory. My desktop does show corruption - it just defaulted to XAA, while laptop (rv350) explicitly had EXA. I assumed EXA would be today's default.

I'll check back in a few days when the latest round of EXA patches hit master. Just a question - Why do I get XAA by default on git drivers?
Comment 8 Alex Deucher 2009-12-02 14:05:18 UTC
(In reply to comment #7)
> I'll check back in a few days when the latest round of EXA patches hit master.
> Just a question - Why do I get XAA by default on git drivers?
> 

If the card has limited vram or the DRI is disabled, it falls back to XAA.
Comment 9 Michel Dänzer 2009-12-02 15:03:15 UTC

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

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.