Created attachment 259811 [details]
random noise

Created attachment 259821 [details]
correct rendering

According to Behdad this might be a cairo issue that is already fixed in trunk. 
I'll test that hypothesis at some point.

Same here. Opening a bunch of web pages in firefox seems to mitigate it, i guess
by exhausting some server side (video?)memory cache.

See also: https://bugs.freedesktop.org/show_bug.cgi?id=13224

I'm seeing this too, I find it strange though that Bill says in:
https://bugs.freedesktop.org/show_bug.cgi?id=13224

That updating to the latest intel driver git fixes this, as I've seen it on an
intel some time ago (and didn't report it because that was like 2 days after the
new X hit rawhide, after that I reverted to F-8 X), but now (first time I tried)
I'm seeing the same problem on my ati radeon 9800 pro (x86_64 machine).

Reverting to F-8 X server + drv (and the drv is almost identical AFAIK) fixes
things, so either this is caused by an X-server issue, or this is a "feature" of
the new server for which all drivers need patching.

Reproduction is trivial in my case, just try to add a comment to a bugzilla bug,
all text typed in the comment textbox is garbled most of the time, thus I'm
typing this from a rawhide install with X-server + drv reverted to F-8

Still seeing this with nv in current rawhide.

Ajax, this very bad X (rawhide) bug somehow got assigned to the reported instead
of you, changing assignee to you.

(In reply to comment #7)
> Still seeing this with nv in current rawhide.

That definitely confirms that this most likely is a server issue not a driver
one. I've tried the following:
-install F-8 X server + devel package
-build latest ati driver from devel branch in CVS

Works fine, where as the latest ati driver build and used against X as in
rawhide results in this font corruption problem. Notice that there is a separate
bug for this against the ati driver, bug 425401, which can probably be closed as
a dup of this one.

p.s. I'm changing the blocker from the generic F-9 blocker to the F-9 X blocker.

*** Bug 433600 has been marked as a duplicate of this bug. ***

I just updated to the latest xserver and ati driver from rawhide:
xorg-x11-server-Xorg-1.4.99.1-0.23.20080222.fc9
xorg-x11-drv-ati-6.8.0-1.fc9

And this still happens, can we please, pretty pretty please have this fixed. Are
the any clues where this is coming from, if I have some idea where to look I
could try taking a stab at fixing this myself.

(In reply to comment #10)

> And this still happens, can we please, pretty pretty please have this fixed. Are
> the any clues where this is coming from, if I have some idea where to look I
> could try taking a stab at fixing this myself.

Not the sort of bug that begging magically fixes, sorry.

I've only seen this with non-antialiased fonts, so if I had to guess, I'd say
the X server is creating glyphs with garbage contents for some reason.

*** Bug 425401 has been marked as a duplicate of this bug. ***

I think this bug might contain some hints:
https://bugs.freedesktop.org/show_bug.cgi?id=7681

Specifically the function which probably is broken now (but only with XAA not
with EXA) is XRenderAddGlyphs or maybe XRenderCompositeText, Also see:
https://bugs.freedesktop.org/show_bug.cgi?id=7494

Extra data point: I'm still seeing it with nv as of today. It doesn't seem to
occur with nouveau.

I have the same problem on up-to-date rawhide (2008.04.16) on both nv and nvidia
drivers.
Fonts are rendering with noise in gnome and kde3 apps, though on kde4 everything
seems OK.

Note: this has been fixed for me (radeon r300, x86_64) for some time now.

Matthias?

(In reply to comment #12)
> *** Bug 425401 has been marked as a duplicate of this bug. ***

Current rawhide behaves correctly with respect to the issue reported in
bug 425401 which was an XAA issue. I am only wondering whether the bug
has been resolved or the following entry in Xorg.0.log is correct:

 "(II) RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700
  and newer. Please use EXA instead."

The card is an ATI X800, so this would apply implying that no render
acceleration is enabled which explain that the issue is gone. However,
one reads later on:

 "(II) RADEON(0): Using XFree86 Acceleration Architecture (XAA)"

I am experiencing this on Rawhide today, in emacs. Select 7x13 font and get
garbage in colored text. Should this be a new bug?

Created attachment 303550 [details]
emacs garbage rendering

Adam, please attach your X server config file (/etc/X11/xorg.conf) and X server
log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

*** Bug 443923 has been marked as a duplicate of this bug. ***

It's not happening once I upgrade to xorg-x11-drv-i810-2.2.1-22.fc9. I assume it
is because EXA is now default. I will manually switch to XAA and attach the logs.

Created attachment 303829 [details]
intel xorg.conf

Created attachment 303830 [details]
intel xorg log

Matthias can you try

Option "XaaNoScanlineCPUToScreenColorExpandFill"

in the Device section of your xorg.conf?

I can reproduce this nv bug on G80 hw by running openoffice in japanese with
sazanami mincho fonts installed (one of my local i18n guys showed it to me..)

I've no idea how we can fix this I'll gladly turn off that option in the nv
driver and let it keep going at this stage..

I'll consult the ajax-oracle... AJAX?? :-)

I'm seeing garbled fonts in the GNU Emacs splash screen on Radeon RV250
[Mobility FireGL 9000] (rev 02). I have

xorg-x11-server-Xorg-1.4.99.901-26.20080415.fc9.i386
xorg-x11-drv-ati-6.8.0-10.fc9.i386
freetype-2.3.5-4.fc9.i386 (recompiled with patented algorithms enabled)
emacs-23.0.60-2.fc9.i386

My xorg.conf is as written by the installer/pyxf86config. It only has a minimal
Device section: 

Section "Device"
        Identifier  "Videocard0"
        Driver      "radeon"
EndSection

I'll attach a screenshot and Xorg log.

Created attachment 304016 [details]
Screenshot re #27

Emacs splash screen appears like this every time. Otherwise font rendering
appears to work in Emacs.

Created attachment 304017 [details]
Xorg log re #27

> I can reproduce this nv bug on G80 hw by running openoffice in japanese with
> sazanami mincho fonts installed (one of my local i18n guys showed it to me..)

That would be bug 443735 btw.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Created attachment 305496 [details]
xorg log

It seems that I am too experiencing this bug, but in gvim for me. The text
displayed by gvim is displayed like lines of noise. I use x300 ati card, gvim is
set to use terminus fonts.

Created attachment 305497 [details]
screenshot of the corrupted gvim window

Created attachment 305498 [details]
xorg.conf file

The bug is disappeared if I enable EXA accel method. Anaconda installer did not
set EXA during installation. System is Fedora 9.

I tried today, but failed to reproduce the 'lines of noise' problem with nv and
rawhide today. But it looks like the bug lives on on the radeon side, judging
from Alexanders comments.

No, it is doubtful that it is just radeon, because intel driver is still broken
as late as xorg-x11-drv-i810-2.2.1-22.fc9. It is possible they have the same bug
separately, or trigger the same bug in common code.

I noticed the same problem on another machine with nvidia proprietary driver
installed. The machine is running Fedora 9 with all latest updates installed.

I see this too every time I put a Fedora Live image in qemu-kvm.

... just after logging in on the gnome-panel with both F9 and F10.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.