| Summary: | x11-base/xorg-server-1.5.3: garbled (antialiased) fonts after upgrade | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Till Matthiesen <entropy> |
| Component: | [OLD] Unspecified | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ag+services, christian.glindkamp, diegoliz, galtgendo, geekounet, gentoo, non7top, tsdh |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| URL: | http://bugs.freedesktop.org/show_bug.cgi?id=19233 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 251832 | ||
| Attachments: |
Screenshot
Screenshot after changing font to Bitstream current Xorg.0.log qtconfig with subpixel rendering enabled qtconfig with subpixel rendering disabled |
||
|
Description
Till Matthiesen
2008-12-16 22:36:40 UTC
Created attachment 175527 [details]
Screenshot
update: No improvements with xf86-video-intel-2.5.1-r1 for me. Are you sure only 1.5.3 is the package to blame? Any chance you updated fontconfig along with xorg-server? Thanks As far as I can tell from emerge.log the following updates have been emerged. xorg-server 1.5.2 --> 1.5.3 xf86-input-evdev 2.0.8 --> 2.1.0 fontconfig has not been updated. It's still at the newest version (2.6.0-r2), emerged back in Oct. So to me it pretty much looks like this is somehow connected to the xorg-server package. Not sure though. Thanks for looking into this. (In reply to comment #4) > xorg-server 1.5.2 --> 1.5.3 > xf86-input-evdev 2.0.8 --> 2.1.0 Hum, could you try downgrading the intel driver to 2.4.3 ? Thanks I had a similar problem, perhaps it's the same one. After upgrade to xorg-server-1.5.3, the font rendering of all windows belonging to 'root' (started with kdesu) was faulty, very much like shown in the screenshot, but not for user windows (except for Mathematica, but that was always a bit 'special', font-wise). After I switched root's kde default fonts to Bitstream instead of the default 'Sans serif' (like I have for my user account), everything went back to normal. Oddly enough, replacing the bundled Mathematica qt libs with symlinks to the system's libs resolved its problem. I can also report font rendering problem with xorg-server-1.5.3 I also did the check. The issue is really originating from this special version. I just downgradeded to 1.5.2 and the issue is gone. My problem with 1.5.3 is that texts containing kanji aren't displayed correctly. The symbols are just replaced by some box symbols containing garbage (or some numbers, dunno - the point is that it's not the correct symbol). This affects nearly every application running on X. My filemanager emelfm2, the xfce4 filemanager thunar, the open dialogues, the Seamonkey webbrowser. I'm using xf86-video-intel-2.5.1-r1, but that doesn't seem to have any effect on the bug. (In reply to comment #8) > I'm using xf86-video-intel-2.5.1-r1, but that doesn't seem to have any effect > on the bug. Has anyone actually tried downgrading the Intel driver to 2.4.3? Thanks It's NOT the intel driver, as on my system with an ATI radeon 9200 with the xorg driver it's pretty much the same effect... (In reply to comment #10) > It's NOT the intel driver, as on my system with an ATI radeon 9200 with the > xorg driver it's pretty much the same effect... Well that's an interesting tidbit :) Now I would really like to know how you guys all get this. What desktop do you run, which settings do you have, maybe your Xorg.0.logs, which applications/toolkits trigger the bug, ... Thanks Oh, and if you're running a compositor, please try to switch it off. Thanks Hi! I checked downgrading to xf86-video-intel-2.4.3. That does not change the situation in any visible way. Now I'm back again at 2.5.1-r1. On the other hand I tried changing the font as Andreas post suggests. Indeed it got marginally better, though not perfect. See screenshot2.png: I marked the text in the post-it plasma application where text is supposed to show up. Additionally you can still see strange things going on at the very bottom of the konqueror window. Btw, my notebook that is equipped with an Ati 9600 Mobility chipset runs xorg-server-1.5.3 with xf86-video-ati-6.9.0 - flawless. Thanks again! Created attachment 175875 [details]
Screenshot after changing font to Bitstream
Created attachment 175878 [details]
current Xorg.0.log
I currently do not use a compositor since it never properly worked for me.
The built-in Kwin compositor becomes dog slow after a few seconds/minutes and showing screen corruptions (once it got slow).
Hopefully things are changing with the upcoming GEM release...
I'm just running a KDE4.1 Desktop without desktop effects. Aliased fonts with xorg-server-1.5.3 show up grabled on QT4-apps. In firefox the menu-fonts are unaliased but readable, the websites seem to be rendered with aliased fonts. If I switch font aliasing off, the QT4-apps are somewhat "ugly" but useable... I just downgraded to 1.5.2 and everything is normal again. Ok well, I can reproduce on my 855 laptop... That ought to help a bit :) Thanks Pretty much same here, after switching from 1.5.2 to 1.5.3 some games which are not using fontconfig (old games) don't show fonts at all anymore. Same goes with urxvt, and some other apps using X core fonts instead of fontconfig. AFAIK. @qt herd, I'm putting you guys in the loop as it seems only Qt apps are affected. As for me I can reproduce the bug with "qtconfig" with a clean profile (ie, default Qt settings). If you guys have any idea what could be going wrong on the Qt side of things, please shout :) Thanks (In reply to comment #18) > Pretty much same here, after switching from 1.5.2 to 1.5.3 some games which are > not using fontconfig (old games) don't show fonts at all anymore. Same goes > with > urxvt, and some other apps using X core fonts instead of fontconfig. Hum, core fonts... Interesting, Donnie put in a patch to use built-in fonts instead of shared fonts. I'll look into that as well. Thanks for the heads up :) I also had problems with fonts after the 1.5.2 -> 1.5.3 upgrade. Mainly with the fixed font. Both urxvt and ion are configured to use 6x13. These became a little bigger than normal. And when I tried to use a smaller version in urxvt, it didn't start at all. Downgrading to xorg-server 1.5.2 solved the problems. Unfortunatly, I did not save the error message of urxvt when using the smaller font. If it would help, I would again upgrade xorg-server to reproduce it. @all,
if you could all copy the 1.5.3 ebuild to a local overlay and comment out line #281 ("${FILESDIR}/1.5.3-builtin-fonts.patch") and then emerge 1.5.3 again, that would be great.
I'm in the middle of a b0rked upgrade so I can't test this yet. Testing without the built-in fonts patch would be *greatly* appreciated :)
Thanks
(In reply to comment #22) > if you could all copy the 1.5.3 ebuild to a local overlay and comment out line > #281 ("${FILESDIR}/1.5.3-builtin-fonts.patch") and then emerge 1.5.3 again, > that would be great. Doing that leaves me completely without X, because my window manager cannot find the fixed font at all and therefore refuses to start. Erf, sorry I mislead you, the change was not that simple. But even doing it correctly doesn't fix the issue (at least for me). I really wonder how Qt draws its fonts... Thanks So I reproduced this on X1600 as follows (having not ran any qt4 configuration before): Launch qtconfig, fonts are shown with default Arial font Go to "fonts" tab select Sans Serif in the topmost combobox file -> save file -> exit ~/.config/Trolltech.conf now has a line saying: font="Sans Serif,12,-1,5,50,0,0,0,0,0" restart qtconfig, see all the problems. If fc-match sans-serif doesn't give dejavu or something, it might be OK, then select Dejavu from fonts instead of the Sans Serif alias. actually if I select "DejaVu Sans" directly, instead of the Sans Serif alias, everything is fine... Unfortunately, the Xorg stack from git fails miserably with my aging 855GM chipset. So I cannot confirm the bug on git master. I would *truly* appreciate if anyone could reproduce this bug with an all "git" Xorg stack from the x11 overlay. The upgrade (and then downgrade) process is fairly straightforward. If any of you guys want to help but feel put off by the x11 overlay, please contact me privately so I can guide you through the process. FWIW, on a recent core 2 duo machine, the whole upgrade shouldn't take more than 45min~1h. Thanks I can confirm this on latest ~x86 with fglrx driver. For me some glyphs in cyrillic fonts in tab names in firefox2 (with xfce theme) running in kde3 were replaced with wrong ones. Downgrading to xorg-server-1.5.2 resolved the issue. (In reply to comment #22) > @all, > > if you could all copy the 1.5.3 ebuild to a local overlay and comment out line > #281 ("${FILESDIR}/1.5.3-builtin-fonts.patch") and then emerge 1.5.3 again, > that would be great. > > I'm in the middle of a b0rked upgrade so I can't test this yet. Testing without > the built-in fonts patch would be *greatly* appreciated :) > > Thanks > Shouldn't be commented also --with-default-font-path=built-ins ? (In reply to comment #29) > Shouldn't be commented also --with-default-font-path=built-ins ? Yes but that's not the cause of the bug, I've tried this myself. This patch makes no difference whatsoever. Comparing with git master is the only way to figure this out. Thanks (In reply to comment #30) > (In reply to comment #29) > > Shouldn't be commented also --with-default-font-path=built-ins ? > > Yes but that's not the cause of the bug, I've tried this myself. This patch > makes no difference whatsoever. Well, perhaps not for the initial bug description, but also removing the configure option makes xorg-server-1.5.3 behave like 1.5.2 in regard to the 'fixed' font. So, that fixes at least my font problems with 1.5.3, which means, these are most probably two different bugs. (In reply to comment #27) > Unfortunately, the Xorg stack from git fails miserably with my aging 855GM > chipset. So I cannot confirm the bug on git master. > > I would *truly* appreciate if anyone could reproduce this bug with an all "git" > Xorg stack from the x11 overlay. The upgrade (and then downgrade) process is > fairly straightforward. > > If any of you guys want to help but feel put off by the x11 overlay, please > contact me privately so I can guide you through the process. FWIW, on a recent > core 2 duo machine, the whole upgrade shouldn't take more than 45min~1h. > > Thanks > Unfortunately I won't be able run any tests within the next two weeks. The setup in question is located at work. Btw, Merry Christmas! Well it looks like upstream knows about this bug too. So it seems it's not entirely my fault after all ;) Thanks (In reply to comment #10) > It's NOT the intel driver, as on my system with an ATI radeon 9200 with the > xorg driver it's pretty much the same effect... @Knut, here's what upstream said about radeon stuff : "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." So this might be an Intel bug after all. If you could test the -9999 radeon driver from the x11 overlay to confirm that the bug is gone, we would all appreciate it :) Thanks I upgraded the kernel to 2.6.28 (vanilla) and gave the x11-overlay a try. mesa-7.2 -> 9999 libdrm-2.4.1 -> 9999 xorg-server-1.5.3 -> 1.5.99.3 (emerge failed on 9999) xf86-video-intel-2.5.1-r1 -> 2.5.99.1 and 9999 No improvements for me concerning the font issue. *** Bug 253808 has been marked as a duplicate of this bug. *** (In reply to comment #35) > mesa-7.2 -> 9999 > libdrm-2.4.1 -> 9999 > xorg-server-1.5.3 -> 1.5.99.3 (emerge failed on 9999) > xf86-video-intel-2.5.1-r1 -> 2.5.99.1 and 9999 > > No improvements for me concerning the font issue. Yeah, after seeing the upstream bug, I'm pretty sure the issue is not specific to my xorg-server patch series. Thanks for testing. On comment 34: x11-drivers/xf86-video-ati-6.9.0 Radeon 9600 EXA (!!!) xorg-server-1.5.3 and...the bug is definitely there. Also (this may be related), in wine's regedit, if I expand enough branches, there's a display problem, that also seems font related: background of the text turns black on some of the branches. (In reply to comment #38) > On comment 34: > x11-drivers/xf86-video-ati-6.9.0 > Radeon 9600 Could you try with a git version of the ati driver? Upstream says EXA bugs were fixed there very recently. Thanks for testing :) For now disabling sub-pixel rendering at font anti-aliasing dialog seems to be a work-around for me. Good compromise, no font corruption so far. Should have tried that earlier... I've tried the xf86-video-ati-9999 driver from the x11 overlay with my radeon 9200. Sorry, the error is still there... This evening I will try to disable the sub-pixel rendering as in comment #40... (In reply to comment #41) > I've tried the xf86-video-ati-9999 driver from the x11 overlay with my radeon > 9200. > Sorry, the error is still there... Could you take a screen shot of qtconfig and attach it here? Let's see if it looks like mine or not. Thanks Created attachment 177705 [details]
qtconfig with subpixel rendering enabled
Created attachment 177707 [details] qtconfig with subpixel rendering disabled If I disable subpixel rendering like in comment #40, the fonts are shown. Using this workaround I can stay at xorg-server-1.5.3, waiting for the fixed version... I'm using net-im/skype as the only qt based application on my system therefore I can't configure my fonts with the named qt tools, is there any way to change to disable this "sub-pixel rendering" issue by hand? Anyhow this disappearing of most glyphs is only reproducible when using the intel driver, when switching to vesa this issue seems to be gone and skype is usable as it should be. (In reply to comment #45) > I'm using net-im/skype as the only qt based application on my system therefore > I can't configure my fonts with the named qt tools, is there any way to change > to disable this "sub-pixel rendering" issue by hand? If Skype uses the system Qt, then you should already have "qtconfig" (even though it doesn't appear in any system menus). If not, then I don't know, maybe the qt herd could tell us :) > Anyhow this disappearing of most glyphs is only reproducible when using the > intel driver, when switching to vesa this issue seems to be gone and skype is > usable as it should be. That's normal. Intel provides EXA acceleration, whereas the vesa driver provides no acceleration whatsoever. Since the bug is somewhere in between the EXA bits of the Intel driver and the EXA bits in Xorg, it's quite normal for the vesa driver to be unaffected. Thanks (In reply to comment #46) > (In reply to comment #45) > > I'm using net-im/skype as the only qt based application on my system therefore > > I can't configure my fonts with the named qt tools, is there any way to change > > to disable this "sub-pixel rendering" issue by hand? > > If Skype uses the system Qt, then you should already have "qtconfig" (even > though it doesn't appear in any system menus). If not, then I don't know, maybe > the qt herd could tell us :) I've emerged skype with the qt-static USE-flag in order to prevent it to emerge also the qt-dependencies - therefore I don't got any qt stuff, including the configuration tools on my system right now. I "could" build it without that USE-flag, but as I don't use skype regularly, it doesn't matter to switch to vesa driver for configuration purposes. While phoning, I don't need to read anything as I'm not using the skype-text-chat. > > > Anyhow this disappearing of most glyphs is only reproducible when using the > > intel driver, when switching to vesa this issue seems to be gone and skype is > > usable as it should be. > > That's normal. Intel provides EXA acceleration, whereas the vesa driver > provides no acceleration whatsoever. Since the bug is somewhere in between the > EXA bits of the Intel driver and the EXA bits in Xorg, it's quite normal for > the vesa driver to be unaffected. > Thanks for that description, I didn't know that until yet. And closing fixed, *finally* :) - 1.5.3-r1 is still under p.mask until the patch ball hits the distfiles mirrors - if you use EXA, then -r1 will be fixed - if you use -intel-9999 with UXA, the bug will be fixed too - if you use a released version of -intel with UXA, then the bug will still be there, I need to backport the patch from master. All in all, the issue is closed. Thanks for your patience. The thing is, my problem from comment #21 is not fixed by 1.5.3-r1. Applying advice from comment #22 and comment #29 fixed the problem as described in comment #31. Should I file a new bug for this issue? (In reply to comment #49) > The thing is, my problem from comment #21 is not fixed by 1.5.3-r1. Applying > advice from comment #22 and comment #29 fixed the problem as described in > comment #31. Should I file a new bug for this issue? Yes please do, it's a completely different bug, and upstream now has a better patch for it, we just need to get to it. Thanks *** Bug 255082 has been marked as a duplicate of this bug. *** |
