Bug 19233

Summary: Invisible fonts with xorg-server 1.5.99.x/xf86-video-intel 2.5.99.1
Product: xorg Reporter: Bernhard Rosenkraenzer <bero>
Component: Server/Acceleration/EXAAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: high CC: ed, esigra, fatih, galtgendo, haien.liu, ingmar, keithp, otaylor, remi
Version: git   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 17452    
Attachments:
Description Flags
Screenshot showing the problem
none
xorg.conf
none
Xorg.0.log
none
Xorg.0.log
none
Flush bash when vertex buffer overflow
none
Revert-EXA-Use-a-single-large-glyph-cache-pixmap.patch
none
Don't use component-alpha mask for non-component-alpha glyphs
none
Fix none

Description Bernhard Rosenkraenzer 2008-12-22 03:15:58 UTC
Created attachment 21395 [details]
Screenshot showing the problem

After updating from xorg-server 1.5.2 to 1.5.99.3, some text disappears.

The attached screenshot shows an example (text gone missing both in the navigation bar of the website and on the radiobuttons in the main frame).

The same version of Konqueror displays the same page fine with the older X server.
Comment 1 Michel Dänzer 2008-12-22 04:33:47 UTC
Probably a driver issue; please attach the full xorg.conf and Xorg.0.log files.
Comment 2 Bernhard Rosenkraenzer 2008-12-22 05:03:55 UTC
It is a driver problem -- happens with the intel driver (2.5.99.1 and current 2.6 branch git), works with the vesa driver.
Comment 3 Bernhard Rosenkraenzer 2008-12-22 05:04:23 UTC
Created attachment 21401 [details]
xorg.conf
Comment 4 Bernhard Rosenkraenzer 2008-12-22 05:04:49 UTC
Created attachment 21402 [details]
Xorg.0.log
Comment 5 Gordon Jin 2008-12-22 23:53:43 UTC
My first feeling is this is bug#19121, but you are using 2.6.28-rc kernel (so it's GEM kernel), right?
Comment 6 Bernhard Rosenkraenzer 2008-12-23 00:31:32 UTC
Yes, I'm using 2.6.28-rc9 with GEM. I also haven't seen any wrong colors yet, just missing text.
Comment 7 Bernhard Rosenkraenzer 2008-12-23 00:41:32 UTC
It might be a random coincidence, but so far I think I've only seen text using
bitmap fonts go missing. (Bitmap fonts in general are working though, I use
them in konsole as well without having problems).
Comment 9 zhao jian 2008-12-23 01:18:48 UTC
We can't reproduce it both with 2.6.28-rc8 and rc9. 

Host:           gm45
Arch:           i386
OSD:            Fedora release 10 (Cambridge)
Kernel:         2.6.28-rc8
Libdrm:         (master)0243c9f801a35de3465a0321c02f18a4d07ce5b8
Mesa:           (intel-2008-q4)f96baeaac3ef41260ac3975750627ece073fdce0
Xorg:           7.2
Xserver:        (server-1.6-branch) 32e81074b967716865aef08b66ec29caf0fec2c5
Xf86_video_intel:    
(xf86-video-intel-2.6-branch)83f3c376b5942e134047a220e6e5f2432ffc492c
GEM_kernel:  (for-airlied)88493410cbe68eb267c540fbb0f6809a1a4124d6
Comment 10 Bernhard Rosenkraenzer 2008-12-24 01:30:17 UTC
Reverting the patch doesn't change anything.

Chances are the reason you aren't seeing the problem on Fedora is that they disable bitmap fonts in the default config (I still haven't seen it happening with any other fonts).

Fonts that go missing usually are "Fixed" and "Helvetica".
Comment 11 Bernhard Rosenkraenzer 2008-12-24 01:39:33 UTC
The problem consistently affects the KDE font selection dialog (I'm using a recent KDE 4.2 snapshot, but KDE 4.1 will probably work the same).

In Konsole, go to Settings -> Edit Current Profile -> Appearance -> Edit Font.

While any font works in Konsole itself, in the selection dialog, the "The Quick Brown Fox..." preview is always invisible for bitmap fonts like "Fixed", "Courier [Adobe]", "Courier [ibm]", "Terminal [Bitstream]", "Terminal [DEC]" and "LucidaTypewriter".

(Make sure bitmap fonts are enabled in fontconfig -- if they aren't, it may just substitute a different font.)
Comment 12 zhao jian 2008-12-25 23:15:05 UTC
I tested in Gnome, and start the Konsole in [System tools]. In Konsole, go to Settings -> Edit Current Profile -> Appearance -> Edit Font, I tried with Fixed[Eten] and Fixed[Misc], the preview will be different with others but still visible. 
Comment 13 Wang Zhenyu 2008-12-28 21:27:09 UTC
Please test with current master, I think this should be fixed in my commit.
commit cfaaf6af777ad8e56da5a077bdc01f4f2d7bc4d6
Author: Zhenyu Wang <zhenyu.z.wang@intel.com>
Date:   Mon Dec 29 21:17:44 2008 +0800

    Don't count vertex buffer in second aperture size check
    
    With batch flush notify vertex buffer will be unreferenced,
    so don't count it in later aperture check. Also adding
    uninitialized vertex buffer check in batch flush notify.
Comment 14 Fatih Aşıcı 2008-12-28 22:22:23 UTC
Created attachment 21541 [details]
Xorg.0.log

Same problem here. cfaaf6af777ad8e56da5a077bdc01f4f2d7bc4d6 does not fix the issue.
Comment 15 Wang Zhenyu 2008-12-28 23:18:46 UTC
Created attachment 21543 [details] [review]
Flush bash when vertex buffer overflow

Please try this one against master. Thanks.
Comment 16 Wang Zhenyu 2008-12-29 00:33:29 UTC
Just install kde4.1 in debian experimental. My konsole has fonts like monospace, courier 10 pitch, dejavu sans mono, liberation mono. All works fine here. Any font package I should choose to install?
Comment 17 Bernhard Rosenkraenzer 2008-12-29 18:12:28 UTC
Still seeing the same problem in today's master. Additionally Xv seems to be broken in that version; videos played with mplayer -vo xv in today's master are very greenish. Other than that (and this bug), today's master works fine.

Make sure you have bitmap fonts enabled, I think all the fonts you've listed are TrueType or Type1 fonts, the issue doesn't show up here with those.

I'm using the bitmap fonts that are distributed with Xorg (/pub/individual/font). Depending on your fontconfig setup, fontconfig automatically replaces bitmap fonts with other fonts; make sure you don't have anything like

  <rejectfont>
   <pattern>
     <patelt name="scalable"><bool>false</bool></patelt>
   </pattern>
  </rejectfont>

in your fontconfig config files (some distros do this by default to make sure all fonts can be scaled and antialiased).

I don't know if the defaults are the same across all versions of fontconfig either (I'm using 2.6.0), you may have to explicitly allow it to use bitmap fonts using something like

 <selectfont>
  <acceptfont>
   <pattern>
     <patelt name="scalable"><bool>false</bool></patelt>
   </pattern>
  </acceptfont>
 </selectfont>
Comment 18 Fatih Aşıcı 2008-12-29 20:21:56 UTC
(In reply to comment #15)
> Created an attachment (id=21543) [details]
> Flush bash when vertex buffer overflow
> 
> Please try this one against master. Thanks.
> 

It doesn't fix again. I have realized that only qt (3 or 4) based applications have this problem. I can see bitmap fonts on gtk based applications, xfontsel, etc. Fonts that disappear:

Fixed [Misc]
Teletext
Terminus
Comment 19 Fatih Aşıcı 2009-01-01 15:13:41 UTC
(In reply to comment #18)
> It doesn't fix again. I have realized that only qt (3 or 4) based applications
> have this problem. I can see bitmap fonts on gtk based applications, xfontsel,
> etc. Fonts that disappear:
> 
> Fixed [Misc]
> Teletext
> Terminus
> 

I can see these fonts if antialiasing is disabled.
Comment 20 Bernhard Rosenkraenzer 2009-01-02 15:26:20 UTC
The problem is in EXA acceleration -- it goes away if I specify Option "AccelMethod" "UXA"
Comment 21 Rémi Cardona 2009-01-04 10:24:12 UTC
I should have checked here earlier, we've had this bug in Gentoo ever since I backported the EXA glyph cache from xserver master onto 1.5.3.

But we've found that this bug is not Intel specific. http://bugs.gentoo.org/251242#c10 says he can reproduce with a radeon card.

People also tried to downgrade the intel driver to 2.4.3, but keeping my heavily patched 1.5.3 server, to no avail. Going back to an un-patched 1.5.3 temporarily fixed the issue.

Everything leads us to believe the glyph cache is the culprit but since no-one had the time to try going to full git master X stack, I wrote the bug off as being my fault when backporting the glyph cache from master...

Here's to hoping it'll help someone figure out what's wrong.

Maybe this needs to be reassigned?

Cheers
Comment 22 Bernhard Rosenkraenzer 2009-01-04 10:35:36 UTC
The reason this got reassigned to the Intel driver in the first place is that it doesn't happen with the VESA driver -- but of course the VESA driver is the worst test case there is given it can't possibly hit accelerated code paths.

A small correction to the previous statement that switching from EXA to UXA fixes it though: UXA makes most problems go away (e.g. the font selection dialog works perfectly), but still shows the problem occasionally, e.g. when visiting ghostscript.com with Konqueror.

Do EXA and UXA share some glyph cache code?
Comment 23 Rémi Cardona 2009-01-04 10:49:57 UTC
(In reply to comment #22)
> Do EXA and UXA share some glyph cache code?

UXA was a plain copy of the exa/ directory from xorg-server into xf86-video-intel, but I'm not sure if the two are in sync.

That could explain why UXA is unaffected...
Comment 24 Fatih Aşıcı 2009-01-04 15:31:43 UTC
(In reply to comment #14)
> Created an attachment (id=21541) [details]
> Xorg.0.log
> 
> Same problem here. cfaaf6af777ad8e56da5a077bdc01f4f2d7bc4d6 does not fix the
> issue.
> 

This log is already taken with UXA. I can reproduce it with both UXA and EXA.
Comment 25 Wang Zhenyu 2009-01-04 18:20:06 UTC
Does intel driver 2.5.99 works in xserver 1.5.3 with EXA and UXA? 

If xserver 1.5.3 works, git bisect exa might help to track this down.
Comment 26 Michel Dänzer 2009-01-05 00:54:25 UTC
(In reply to comment #21)
> But we've found that this bug is not Intel specific.
> http://bugs.gentoo.org/251242#c10 says he can reproduce with a radeon card.

The radeon driver had R200 RENDER acceleration bugs that were only recently fixed in Git; please have those people try again with current xf86-video-ati Git.

I can't seem to reproduce this with an RV350 neither in konqueror (can't seem to force bitmap fonts on rpm.pbone.net, but they render just fine e.g. on lwn.net) nor in konsole.

Comment #13 of the downstream bug above seems to confirm my observations, so before reassigning this to the EXA core I'd like to have a way to reproduce with the radeon driver on non-R200 hardware.
Comment 27 Gordon Jin 2009-01-05 19:30:14 UTC
*** Bug 19396 has been marked as a duplicate of this bug. ***
Comment 28 Rémi Cardona 2009-01-07 03:27:31 UTC
(In reply to comment #26)
> Comment #13 of the downstream bug above seems to confirm my observations, so
> before reassigning this to the EXA core I'd like to have a way to reproduce
> with the radeon driver on non-R200 hardware.

The user who wrote that comment said he can still reproduce with the radeon driver from git. Could he still be having R200-specific issues?

Thanks
Comment 29 Michel Dänzer 2009-01-07 03:42:56 UTC
Does

    Option "EXAOptimizeMigration" "off"

work around the problem?
Comment 30 Bernhard Rosenkraenzer 2009-01-07 07:18:41 UTC
Option "EXAOptimizeMigration" "off" doesn't change anything.
Comment 31 Michel Dänzer 2009-01-08 01:27:29 UTC
(In reply to comment #28)
> The user who wrote that comment said he can still reproduce with the radeon
> driver from git.

Bummer.

> Could he still be having R200-specific issues?

Possibly, given that I haven't been able to reproduce with an RV350. Have you seen any reports of people seeing this with >= R300 class hardware?
Comment 32 Rémi Cardona 2009-01-08 01:38:58 UTC
(In reply to comment #31)
> Possibly, given that I haven't been able to reproduce with an RV350. Have you
> seen any reports of people seeing this with >= R300 class hardware?

Unfortunately no. Save for this one user, only Intel users have been noticing this so far.

I'll fish around for other testers.

Thanks
Comment 33 Rafał Mużyło 2009-01-08 13:52:07 UTC
Well, I'm on RV350 AP [Radeon 9600] and can see the problem
i.e. in opera.
Comment 34 Michel Dänzer 2009-01-09 01:00:18 UTC
(In reply to comment #33)
> Well, I'm on RV350 AP [Radeon 9600] and can see the problem
> i.e. in opera.

You'll have to provide a lot more information about how to reproduce, in particular things like font settings, which site(s) it happens on, ...
Comment 35 Rémi Cardona 2009-01-09 02:14:59 UTC
A few other testers and myself were able to reproduce this with a simple Qt app that just shows a text label. That requires the default Qt font settings (which we don't modify in Gentoo IIRC).

Or just launching "qtconfig" is enough to see the bug (again with the default settings). See attachments in our bug tracker.
Comment 36 Michel Dänzer 2009-01-09 05:43:56 UTC
(In reply to comment #35)
> See attachments in our bug tracker.

Sigh, the upstream report needs to have all the relevant information directly...

I think the key is the sub-pixel anti-aliasing. I still haven't been able to reproduce (can't seem to force sub-pixel AA in Qt, possibly because KDE incorrectly thinks my laptop panel isn't an LCD...), but here's my theory what happens:

Since sub-pixel AA is enabled, exaGlyphs() probably gets PICT_a8r8g8b8 for maskFormat. However, bitmap font glyphs are PICT_a1 (so the PICT_a8 glyph cache pixmap is used). I suspect the problem is that the exaCompositeRects(PictOpAdd, ...) call in exaGlyphsToMask only adds to the alpha channel of the PICT_a8r8g8b8 mask, not to the colour channels. So the final composition step doesn't affect the colour channels of the destination at all.

Seeing whether reverting xserver commit 8349732a6720652bfbad7874a952be73a0e8e77b works around the problem or generally bisecting which commit made it visible could help confirm or reject this theory.

If the theory is correct, whether it's a bug in EXA or the drivers depends on whether the result of PictOpAdd from PICT_a1/8 to PICT_a8r8g8b8 is supposed to increase the colour channels of the latter. This isn't clear to me from a quick look at renderproto.txt; Keith/Owen?
Comment 37 Rafał Mużyło 2009-01-09 09:51:08 UTC
(In reply to comment #34)
> 
> You'll have to provide a lot more information about how to reproduce, in
> particular things like font settings, which site(s) it happens on, ...
> 
Not sites, problem shows on menus and dialogs.
As for details:
Gentoo
xorg-server-1.5.3
xf86-video-ati-6.9.0
EXA
Comment 38 Bernhard Rosenkraenzer 2009-01-09 11:27:08 UTC
Reverting 8349732a6720652bfbad7874a952be73a0e8e77b doesn't change anything.

Running current Ark Linux development branch, versions of potentially relevant packages are
xorg-server 1.5.99.4
xf86-video-intel 2.5.99.2
libXft 2.1.13
libXfont 1.3.4
fontconfig 2.6.0
Qt 4.5.0-snapshot-20090105
kernel 2.6.28 (GEM enabled)
mesa 7.3-snapshot-20081222
Comment 39 Fatih Aşıcı 2009-01-09 13:32:35 UTC
Created attachment 21843 [details] [review]
Revert-EXA-Use-a-single-large-glyph-cache-pixmap.patch

Reverting 54184110f6f3e5d7276d5431e739a4fcf0c3523e fixes the problem. Since it is not reverted cleanly, I am attaching the patch here.
Comment 40 Michel Dänzer 2009-01-11 09:02:57 UTC
Created attachment 21885 [details] [review]
Don't use component-alpha mask for non-component-alpha glyphs

If my theory from comment #36 is correct or at least close, this patch (only compile tested) may help.
Comment 41 Fatih Aşıcı 2009-01-11 10:38:13 UTC
(In reply to comment #40)
> Created an attachment (id=21885) [details]
> Don't use component-alpha mask for non-component-alpha glyphs
> 
> If my theory from comment #36 is correct or at least close, this patch (only
> compile tested) may help.
> 

I have tried applying it on top of master branch and it doesn't help.
Comment 42 Michel Dänzer 2009-01-12 01:32:34 UTC
(In reply to comment #39)
> Reverting 54184110f6f3e5d7276d5431e739a4fcf0c3523e fixes the problem. Since it
> is not reverted cleanly, I am attaching the patch here.

Your patch just removes the glyph cache completely, which isn't a feasible solution.

Isn't there any commit between 54184110f6f3e5d7276d5431e739a4fcf0c3523e and 8349732a6720652bfbad7874a952be73a0e8e77b where this isn't broken?
Comment 43 Fatih Aşıcı 2009-01-12 13:47:53 UTC
(In reply to comment #42)
> Isn't there any commit between 54184110f6f3e5d7276d5431e739a4fcf0c3523e and
> 8349732a6720652bfbad7874a952be73a0e8e77b where this isn't broken?

I have tried all of the commits between those; none of them works correctly.
Comment 44 Michel Dänzer 2009-01-13 04:16:19 UTC
I was finally able to reproduce and analyze the problem on another machine. Looks like with sub-pixel AA enabled, Qt actually uses component-alpha glyphs even for bitmap fonts, but no mask. This broke because EXA failed to declare the 32 bit glyph cache pictures as component-alpha.

Fixed in the xserver commit below, leaving this report open until it's backported to the 1.6 branch.

commit 639f289dcdbe00a516820f573c01a8339e120ed4
Author: Michel Dänzer <daenzer@vmware.com>
Date:   Tue Jan 13 13:05:32 2009 +0100

    EXA: Declare glyph cache picture as component-alpha when necessary.
    
    Without this, rendering component-alpha glyphs may break without a mask.
Comment 45 Bernhard Rosenkraenzer 2009-01-13 06:18:34 UTC
Created attachment 21934 [details] [review]
Fix

FWIW here's the same patch relative to 2.5.99.901
Comment 46 Eric Anholt 2009-01-30 17:01:57 UTC
commit 9e03178ae2da6beb939141f662d875c4c1d40354
Author: Michel Dänzer <daenzer@vmware.com>
Date:   Tue Jan 13 13:05:32 2009 +0100

    EXA: Declare glyph cache picture as component-alpha when necessary.
    
    Without this, rendering component-alpha glyphs may break without a mask.
    
    Fixes http://bugs.freedesktop.org/show_bug.cgi?id=19233 .
    (cherry picked from commit 639f289dcdbe00a516820f573c01a8339e120ed4)

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.