Bug 13104

Summary: font corruption on current xorg xserver git
Product: xorg Reporter: Hanno Böck <hanno>
Component: Server/Acceleration/XAAAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: ajax, bero, cryos, gregua, jlp.bugs, jwrdegoede, lam, matthieu.herrb, ossi, sb476
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 10101    
Attachments:
Description Flags
screenshot of corruption none

Description Hanno Böck 2007-11-05 14:25:52 UTC
I'll attach a shot of the corruption. Happens to all pcf fonts.

A guy kr992 posted the same corruption on the xorg-list.
Comment 1 Hanno Böck 2007-11-05 14:26:12 UTC
Created attachment 12363 [details]
screenshot of corruption
Comment 2 Benjamin Close 2007-11-15 20:20:00 UTC
Mailing list:

http://lists.freedesktop.org/archives/xorg/2007-October/029836.html

No follow up.

Seems driver independant as breaks with nv driver as wll
Comment 3 Benjamin Close 2007-11-19 16:55:55 UTC
*** Bug 13212 has been marked as a duplicate of this bug. ***
Comment 4 Michel Dänzer 2007-11-19 23:52:28 UTC
Does this also happen with xserver 1.4? If not, can you try and isolate the change that introduced it with git-bisect?
Comment 5 Oswald Buddenhagen 2007-11-20 02:33:26 UTC
i'm seeing this on i845G, but only with XAA - EXA works fine (in this regard, heh).
Comment 6 Hanno Böck 2007-11-21 10:50:00 UTC
It doesn't happen with 1.4. I posted this first on 31.10., happened a few days before. I'll try to isolate it further when I find time for it.
Comment 7 Benjamin Close 2008-01-07 20:43:45 UTC
Possible Temporary solution:

Option  "XAANoOffscreenPixmaps"

may fix it (see thread)

http://lists.freedesktop.org/archives/xorg/2007-December/031113.html
Comment 8 Oswald Buddenhagen 2008-01-08 00:20:49 UTC
nope ...
Comment 9 Michel Dänzer 2008-01-08 00:22:48 UTC
Can everybody confirm that this only happens with XAA?
Comment 10 Benjamin Close 2008-01-08 14:08:20 UTC
Fixes the issue for me:

nv driver

xserver: origin/mpx 20ace6321ac464d821c67a82c7023f74ae038176
Comment 11 Benjamin Close 2008-01-08 16:57:59 UTC
Reported too early. It partially fixed the problem. Email now displays correctly but a pop up menu still is broken.
Comment 12 Michel Dänzer 2008-02-05 03:28:04 UTC
*** Bug 14382 has been marked as a duplicate of this bug. ***
Comment 13 Bernhard Rosenkraenzer 2008-02-05 05:40:01 UTC
I can reproduce this problem with the radeonhd and mga drivers, I don't see it with intel (945GM) and ati (9200).
Comment 14 Michel Dänzer 2008-02-05 06:56:47 UTC
(In reply to comment #13)
> I can reproduce this problem with the radeonhd and mga drivers, I don't see it
> with intel (945GM) and ati (9200).

Have you tried XAA vs. EXA with all drivers (where applicable)?
Comment 15 Bernhard Rosenkraenzer 2008-02-05 07:06:59 UTC
Looks like an XAA problem --

Option "AccelMethod" "EXA" fixes it on radeonhd and mga
EXA is the default for Intel, and the current Intel driver doesn't work at all with XAA.

Can't check ati at the moment (that box is at home)
Comment 16 Bernhard Rosenkraenzer 2008-02-14 09:27:36 UTC
I've just read parts of a diff between 1.4 (working) and current git (broken) - there don't seem to be any relevant changes in xaa code itself (hw/xfree86/xaa), making it likely that xaa just triggers a problem elsewhere
Comment 17 Michel Dänzer 2008-02-14 09:45:16 UTC
Yeah, most likely the glyphs-as-pixmaps changes didn't account for all the quirks of XAA.
Comment 18 Bernhard Rosenkraenzer 2008-02-20 03:27:54 UTC
After some more examination, the problem isn't caused by bitmap fonts, it's caused by antialiasing being off (which is always triggered by bitmap fonts, given they can't be antialiased).

Put this into fonts.conf to reproduce with TTF and Type1 fonts:

 <match target="font">
  <test name="pixelsize" compare="less">
   <double>100</double>
  </test>
  <edit name="antialias" mode="assign">
   <bool>false</bool>
  </edit>
 </match>

Are non-antialiased TTF fonts hit by the suspected glyphs-as-pixmaps changes?
Comment 19 Hans de Goede 2008-02-26 11:40:58 UTC
I'm seeing this to an a variety of machines. Can we please, pretty pretty please have someone take a serious look at this. I'm a skilled coder and I'm willing todo any test builds necessary, we _really_ need to get this fixed!
Comment 20 Marcus D. Hanwell 2008-03-08 11:40:27 UTC
Just to confirm that Option "AccelMethod" "EXA" fixes this font corruption on my 64 bit Gentoo system using latest git builds from this morning. Without that I was seeing widespread font corruption on anything that was not antialiased (I think). Glad there is a workaround but this is a horrible bug.

I would be willing to test any possible fixes too. This is using the r300 radeon driver (latest git build too).
Comment 21 Stuart Bennett 2008-03-15 12:01:30 UTC
Broke with a2af34d5a861982a03afad8e586bb0181b72bbd0 "Use per-screen Pixmaps for glyphs"
Comment 22 Adam Jackson 2008-05-06 14:55:06 UTC
AFAICT this is because glyph pictures get created in card memory, and then hit an XAA fast path that assumed glyph contents were always in host memory.  Fortunately we can catch the creation of glyph pictures and force them to never get created in card memory.

Commit 718652eaf9221e0eeec2c971dd7baa97f827451b should address this.  I think.
Comment 23 Stuart Bennett 2008-05-06 15:24:34 UTC
Sadly not (in the nv driver case, at least)
Comment 24 Bernhard Rosenkraenzer 2008-05-06 15:56:19 UTC
Still broken on r200 and r300 too
Comment 25 Adam Jackson 2008-05-07 10:05:13 UTC
Ah, sure.  Not only were we assuming that the bits were in host memory, we were assuming that they were stored after the GlyphRec header itself.  This is, uh... no longer the case.
Comment 26 Adam Jackson 2008-05-08 13:06:40 UTC
Fixed in f17ba5d5849c92603f453195aca384844ca76d74 by ripping out the broken fast path.

If anyone ever wants to fix it better (and I strongly discourage making XAA any better at this point): the bits and pitch variables in the removed code need to be updated to pull their values from the glyph picture.  That's probably not all that was wrong with the code, but it was certainly some of it.
Comment 27 Adam Jackson 2008-05-08 13:15:02 UTC
Both patches cherry-picked to server-1.5-branch, closing.
Comment 28 Hans de Goede 2008-05-08 13:23:12 UTC
Ajax, any chance we will see this fix in F-9 proper, or as a 0 day update?
Comment 29 Oswald Buddenhagen 2008-05-08 16:02:55 UTC
uhm, now, i can confirm that the previous corruption is gone.

instead, glyphs are now truncated vertically - usually, the part around the base line and down is missing. this seems to be a per-invocation phenomenon, as the same truncation happens within a single text fragment, but differs more or less for other ones. happens equally with exa and xaa, though, so might well be something unrelated i sucked in with the last pull. will investigate later if nobody else pins it down.
Comment 30 Adam Jackson 2008-05-12 07:39:06 UTC
(In reply to comment #29)
> uhm, now, i can confirm that the previous corruption is gone.
> 
> instead, glyphs are now truncated vertically - usually, the part around the
> base line and down is missing. this seems to be a per-invocation phenomenon, as
> the same truncation happens within a single text fragment, but differs more or
> less for other ones. happens equally with exa and xaa, though, so might well be
> something unrelated i sucked in with the last pull. will investigate later if
> nobody else pins it down.

My test was using the fonts tab of gnome-appearance-properties, and switching between aliased and anything else.  I don't see vertical truncation there, so it's pretty likely you're seeing something different.
Comment 31 Oswald Buddenhagen 2008-05-12 07:55:12 UTC
yes, somehow the problem resolved itself. maybe it needed a hard reboot after the driver upgrade or something.

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.