Summary: | Glyphs appear as blocks or distorted on EXA only | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Simon Thum <simon.thum> | ||||||
Component: | Driver/Radeon | Assignee: | 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
Simon Thum
2009-12-02 09:24:30 UTC
Created attachment 31664 [details]
screenshot
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] Created attachment 31665 [details] [review] xorg.log log is from an EXA run. 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. (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. does this exa patch help? http://lists.freedesktop.org/archives/xorg-devel/2009-December/003818.html 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? (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. |
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.