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.
Probably a driver issue; please attach the full xorg.conf and Xorg.0.log files.
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.
Created attachment 21401 [details] xorg.conf
Created attachment 21402 [details] Xorg.0.log
My first feeling is this is bug#19121, but you are using 2.6.28-rc kernel (so it's GEM kernel), right?
Yes, I'm using 2.6.28-rc9 with GEM. I also haven't seen any wrong colors yet, just missing text.
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).
Can you try reverting this patch: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=e8b95efbf5d9c3a5b75b2bb8b5b51844b5fcdfbc
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
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".
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.)
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.
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.
Created attachment 21541 [details] Xorg.0.log Same problem here. cfaaf6af777ad8e56da5a077bdc01f4f2d7bc4d6 does not fix the issue.
Created attachment 21543 [details] [review] Flush bash when vertex buffer overflow Please try this one against master. Thanks.
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?
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>
(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
(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.
The problem is in EXA acceleration -- it goes away if I specify Option "AccelMethod" "UXA"
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
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?
(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...
(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.
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.
(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.
*** Bug 19396 has been marked as a duplicate of this bug. ***
(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
Does Option "EXAOptimizeMigration" "off" work around the problem?
Option "EXAOptimizeMigration" "off" doesn't change anything.
(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?
(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
Well, I'm on RV350 AP [Radeon 9600] and can see the problem i.e. in opera.
(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, ...
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.
(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?
(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
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
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.
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.
(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.
(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?
(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.
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.
Created attachment 21934 [details] [review] Fix FWIW here's the same patch relative to 2.5.99.901
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.