Bug 18399 - Bitmap-font glyph corruption in Gnome-terminal [EXA enabled]
Summary: Bitmap-font glyph corruption in Gnome-terminal [EXA enabled]
Status: RESOLVED DUPLICATE of bug 18397
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.4 (2008.09)
Hardware: All Linux (All)
: high normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL: https://bugs.edge.launchpad.net/ubunt...
Whiteboard:
Keywords:
: 18398 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-11-05 14:33 UTC by Bryce Harrington
Modified: 2009-11-11 10:36 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log (60.00 KB, text/x-log)
2008-11-05 14:33 UTC, Bryce Harrington
no flags Details

Description Bryce Harrington 2008-11-05 14:33:12 UTC
Created attachment 20091 [details]
Xorg.0.log

Forwarding this EXA bug from a Ubuntu tester:
https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/291040

[Problem]
glyph corruption in GnomeTerminal when using (non-anti-aliased) bitmap fonts.

[Original Report]
I get consistent and frequent glyph-corruption if I use bitmap-fonts (which are not anti-aliased) in Gnome-terminal. The corruption will almost always be triggered by moving/navigating the cursor over glyphs (thus temporarily inverting the colors). I have attached a screenshot which clearly shows the problem when editing a file in GNU nano.

This corruption only occurs when running a composited desktop using Compiz. I've not seen it happen under Metactiy (with EXA).

Xorg driver in use is xserver-xorg-video-radeon git20081003.f9826a56-0ubuntu2. EXA-acceleration is enabled.
Using Compiz.
Ubuntu 8.10 (fully updated, installed from RC).
Graphics card: ATI X1400 mobile radeon (R500), 128MB RAM.

If more information is needed, please say so. I am also willing and able to test new GIT-snapshots of the radeon driver, and provide feedback if problems are fixed, etc.

[Screenshot of corruption]
http://launchpadlibrarian.net/19073107/bitmapfont-glyph-corruption.png

[lspci]
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon Mobility X1400 [1002:7145]
	Subsystem: Lenovo Device [17aa:202a]
(Full lspci at http://launchpadlibrarian.net/19073109/lspci-vvnn.txt)
Comment 1 Alex Deucher 2008-11-05 16:50:53 UTC
does:
Option "AccelDFS" "False"
help?
Comment 2 Øyvind Stegard 2008-11-06 03:07:24 UTC
Disabling accelerated download-from-screen resolves the corruption issues with bitmap fonts (or non-anti-aliased fonts) in Gnome-terminal. However, it slows down immensely without this kind of acceleration. Scrolling in Gnome-terminal is unbearable, maximizing/minimizing is very slow (probably because this triggers huge redraw-operation).

I prefer it faster with slight corruption ;). Also, notice that when I use a regular anti-aliased font (like Ubuntu's default Monospace), then the corruption _never_ occurs, even with accelerated DFS.

[As another side note, Firefox scrolling seems not to suffer much when disabling accelerated DFS. There's also slightly more tearing when motion is rendered in Compiz.]
Comment 3 Michel Dänzer 2008-11-06 03:27:30 UTC
(In reply to comment #2)
> Disabling accelerated download-from-screen resolves the corruption issues with
> bitmap fonts (or non-anti-aliased fonts) in Gnome-terminal.

So it looks like at least some of the issues you reported boil down to AccelDFS being broken on your setup.

Can you try if the radeon kernel module built from git://anongit.freedesktop.org/git/mesa/drm fixes the AccelDFS issues?

> However, it slows down immensely without this kind of acceleration. Scrolling
> in Gnome-terminal is unbearable, maximizing/minimizing is very slow (probably
> because this triggers huge redraw-operation).
> 
> I prefer it faster with slight corruption ;). Also, notice that when I use a
> regular anti-aliased font (like Ubuntu's default Monospace), then the
> corruption _never_ occurs, even with accelerated DFS.

This is because anti-aliased font rendering is accelerated whereas aliased font rendering is not (which BTW is fixed in current upstream xserver Git).
Comment 4 Øyvind Stegard 2008-11-06 03:35:16 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > Disabling accelerated download-from-screen resolves the corruption issues with
> > bitmap fonts (or non-anti-aliased fonts) in Gnome-terminal.
> 
> So it looks like at least some of the issues you reported boil down to AccelDFS
> being broken on your setup.
> 
> Can you try if the radeon kernel module built from
> git://anongit.freedesktop.org/git/mesa/drm fixes the AccelDFS issues?

I will try this later (when I get home from work ;) and report back.  

<snip>

> This is because anti-aliased font rendering is accelerated whereas aliased font
> rendering is not (which BTW is fixed in current upstream xserver Git).
> 

Ah, I see :). The only place I ever use a non-antialiased-font is in Gnome-terminal, because the classic MiscFixed 6x13 just has unbeatable clarity.
Comment 5 Øyvind Stegard 2008-11-06 08:16:08 UTC
I am not quite familiar with git, yet, but did:

$ git clone git://anongit.freedesktop.org/git/mesa/drm

$ cd linux-core; make

Installed the modules drm.ko and radeon.ko into kernel module tree. Ran a depmod and re-loaded modules and started up X:
[87994.909647] [drm] Num pipes: 1
[87996.157780] [drm] Loading R500 Microcode
[87996.157864] [drm] Num pipes: 1
[87998.280369] [drm] Num pipes: 1
[88041.332267] [drm] Module unloaded
[88066.769737] Symbol init_mm is marked as UNUSED, however this module is using it.
[88066.769757] This symbol will go away in the future.
[88066.769763] Please evalute if this is the right api to use and if it really is, submit a report the linux kernel mailinglist together with submitting your code for inclusion.
[88066.800478] [drm] Initialized drm 1.1.0 20060810
[88066.805623] radeon 0000:01:00.0: setting latency timer to 64
[88066.805902] [drm] Initialized radeon 1.29.0 20080613 on minor 0
[88096.034523] [drm] Setting GART location based on new memory map
[88096.037116] [drm] Loading R500 Microcode
[88096.037228] [drm] Num pipes: 1
[88096.037245] [drm] writeback test succeeded in 1 usecs

The date reported for the radeon module is newer than what comes with Ubuntu, so I'm pretty sure I'm running with the updated module. 

But .. it did not resolve the issue :(. It works fine, but the problems are still there.
Comment 6 Alex Deucher 2008-11-06 13:01:59 UTC
*** Bug 18398 has been marked as a duplicate of this bug. ***
Comment 7 Øyvind Stegard 2008-11-22 07:22:20 UTC
Upating to latest radeon DRM kernel module had another positive side effect, it seems: it fixed OpenGL VSYNC support. I no longer get something like "drmWaitBlank returned -1: IRQs not working" (or similar) when forcing VSYNC through the vblank_mode parameter. I need this because Textured Video has severe tearing problems, while fullscreen OpenGL with VSYNC is perfect for movies. Sorry for the off-topic comment, I'm just happy I can now watch movies properly with the radeon driver :)
Comment 8 Dragos Delcea 2009-06-03 03:22:24 UTC
I'm seeing radio-button corruption in firefox; gentoo 32bit, xorg 1.5.3 (no compiz), latest radeon git (EXA/DRI1 enabled), kernel 2.6.29 - hw is thinkpad t60, radeon mobility x1400.
Comment 9 Øyvind Stegard 2009-06-03 03:52:26 UTC
(In reply to comment #8)
> I'm seeing radio-button corruption in firefox; gentoo 32bit, xorg 1.5.3 (no
> compiz), latest radeon git (EXA/DRI1 enabled), kernel 2.6.29 - hw is thinkpad
> t60, radeon mobility x1400.
> 

Please also see bug 18397, which deals with exactly this problem on ATI X1400 .. 
Comment 10 Dragos Delcea 2009-06-03 04:03:17 UTC
(In reply to comment #9)
> Please also see bug 18397, which deals with exactly this problem on ATI X1400
> .. 
I found bug 18398 (Form check-box corruption in Firefox..) which was closed as a duplicate of this one, that was the reason for posting here..
Comment 11 Øyvind Stegard 2009-06-03 04:25:22 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > Please also see bug 18397, which deals with exactly this problem on ATI X1400
> > .. 
> I found bug 18398 (Form check-box corruption in Firefox..) which was closed as
> a duplicate of this one, that was the reason for posting here..
> 

Yes, I understand. I initially reported four different bugs IIRC, and some of those turned out to be the same problem. Bug 18398 should be a duplicate of bug 18397 instead, because bug 18397 is more complete and has more data.
Comment 12 Alex Deucher 2009-11-11 10:36:48 UTC

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


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.