From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 Galeon/1.3.10 Description of problem: The fonts in Qt and KDE apps are not antialiased anymore. In GNOME/GTK fonts are alright. All configurations for Qt related to Xft are set. I attach an strace of qtconfig3. Version-Release number of selected component (if applicable): qt-3.1.2-14 How reproducible: Always Steps to Reproduce: Login in GNOME desktop (through gdm). Start qtconfig3 or any other Qt or KDE app. Additional info:
Created attachment 95778 [details] strace of qtconfig3
Hm, it looks like that useXft is disable in your config file. Please start "kcmshell fonts" and check if "Use anti-aliasing for fonts" is on Could you please send your $HOME/.qt/qtrc.
Created attachment 95790 [details] $HOME/.qt/qtrc Seems alright. Notice, that delete .qt and .kde to restart cleanly. I also checked the settings in kcontrol and qtconfig3.
Strange, strange. I started qtconfig3 remotely via ssh from an RH9 box. Now fonts are antialiased, although a bit small. Maybe related to this: On both machines with the same NVIDIA driver 4496, on running glxgears, on FC1 I get a Xlib: extension "XFree86-DRI" missing on display ":0.0". on RH9, I don't. The NVIDIA driver doesn't need dri, and on both machines Load "dri" is commented out. So far all OpenGL apps work as expected on FC1, so this warning seems to be harmless. Perhaps I will open a separate bug for this.
It looks like the same problem as in bug #108672 is at work. I switched to TwinView instead of Xinerama, and the fonts in Qt and KDE display anti-aliased. Unfortunately TwinView has its own issues.
Just to confirm the problem Same machine, Red Hat 9 and FC1, using same XF86Config. RH9 with Xinerama has true type fonts everywhere. FC1 with Xinerama enabled does not have truetype fonts in KDE/qt apps. Disabling xinerama restores truetype-ness.
Same problem with dual monitors. No anti-aliasing with xinerama, nice fonts with TwinView.
I have also run into this problem using a radeon 7500 and xinerama. The on bit of info I have to add is that I upgraded the qt in redhat 9 to 3.1.2-14 quite some time before Fedora Core came out and the fonts were fine in qt apps with xinerama enabled. I also play with a DTP app called scribus that is qt based, and it will sometimes hang on start related to fonts. It does not ever hang when xinerama is disabled.
could you please try to install XFree86-4.3.0-2 from RHL9 in Fedora Core. Does this problem still appear?
I installed but of X from RHL9 and this was the outcome. I first downgraded only the Xfree86 rpm with no change in behavior. I then downgraded XFree86-libs XFree86-libs-data and XFree86-xfs. I then restarted X and the problem was gone. Qt apps looked great and all was well. I then upgraded back to the stock Fedora rpms for XFree86, -libs, and -libs-data, and the problem returned. I then upgraded XFree86-xfs to the stock Fedora so I would be back in sink with a stock Fedora install.
I can confirm that downgrading to XFree86-libs-4.3.0-2 from RedHat 9 fixes the problem. I installed the RPM while being logged into my (ugly-looking) KDE session, then ctrl-alt-backspace and logged in again. Problem is gone.
*** Bug 110497 has been marked as a duplicate of this bug. ***
Please see bug 110497 and note: I've tried the new XFree86-libs but with the old libXrender library and that fixes the problem. If I put libXrender.so.1.2 back in all works OK If I put libXrender.so.1.2.2 in it breaks ....
Just looked at source RPMs for new RH90 Xlib packages and note that Xrender/render was upgraded to 0.8.3 - I suspect a prime candidate for the introducing/exposing the problem. I don't know the insides of X well enough to work out the problem on my own but am more than happy to provide any debug logs required. Cheers Mark
This may be related - found this on Mandrake ..... http://qa.mandrakesoft.com/show_bug.cgi?id=5290
Confirmed - Xrender.c 1.18 fixes the problem. From: http://x2.freedesktop.org/cgi-bin/cvsweb/xlibs/Xrender/Xrender.c Make Xrender depth checks work with broken Xinerama code Mark
I believe this bug is now present in Redhat 9 after the recent update of X packages published through RHN (RHSA-2003:288).
ok it seems a problem in XFree86
*** Bug 107473 has been marked as a duplicate of this bug. ***
libXrender 0.8.4 has been released, which appears to contain a fix for this problem. I'm upgrading to it currently for Fedora Core development. Fixed in XFree86-4.3.0-58
As bug 110487 is marked as a duplicate of this bug for RH9. I notice that a new version of XFree86 has come out for RH9 (XFree86-4.3.0-2.90.55) for which this bug is still not fixed. Is the suggested fix for RH9 to get the lastest fedora development package?
As an additional note for Red Hat Enterprise Linux customers who may experience this problem as well, as noted above for Red Hat Linux 9, the current fix for this is considered experimental only for now and not yet tested and production stable. Since we release quarterly updates for RHEL 3, if the new Xft library is considered to be stable in time for the next RHEL 3 quarterly update, this fix may get included. Otherwise it will likely wait until the next quarterly update. The important thing is that the fixes are widely tested before being included in any official OS updates for RHEL 3 and/or RHL9 and/or Fedora Core 1. Hope that helps clarify things a bit.