Red Hat Bugzilla – Bug 496531
Fonts change when config tool starts
Last modified: 2010-06-28 08:05:59 EDT
Not entirely sure what component to file this against. When I right-click on the background and select 'Change desktop background', all my fonts suddenly go tiny, even before the window pops up to let me choose a new background. http://david.woodhou.se/wtf.flv Happens when I select 'System... Preferences... Appearance' from the menu, too. Interestingly, killing gnome-settings-daemon makes the fonts go larger. Not back to normal. But even bigger than that. Confused. I first noticed this after the desktop changed to the lion; I wanted to see if I could switch it back to what I had before. I'm fairly sure things were working before, because I'd been playing with the previous picture (tiling, etc.)
*** Bug 496703 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > Not entirely sure what component to file this against. When I right-click on > the background and select 'Change desktop background', all my fonts suddenly go > tiny, even before the window pops up to let me choose a new background. > > http://david.woodhou.se/wtf.flv That's gnome-settings-daemon starting up and applying your settings to the session. > Happens when I select 'System... Preferences... Appearance' from the menu, too. > > Interestingly, killing gnome-settings-daemon makes the fonts go larger. Not > back to normal. But even bigger than that. Confused. That GTK+ going back to the default font. It didn't know what font/font size the previous one was, so it can't reset it. > I first noticed this after the desktop changed to the lion; I wanted to see if > I could switch it back to what I had before. I'm fairly sure things were > working before, because I'd been playing with the previous picture (tiling, > etc.) So the bug is that gnome-settings-daemon wasn't running. I guess you're using a GNOME desktop? My guess is that this[1] is fixed by the XRandR fixes in g-s-d and libgnomedesktop. Could you please check that gnome-settings-daemon is running when your session starts? [1]: "this" being the fact that gnome-settings-daemon doesn't run on your session startup.
gnome-settings-daemon _was_ running before I did this. And is still running, with the same PID, after the fonts go tiny.
Could I please have the output of those commands before and after the problem happens? xdpyinfo gconftool-2 -g /desktop/gnome/interface/font_name gconftool-2 -R /desktop/gnome/font_rendering I think the control-center is changing the DPI.
Just to make sure we're all on the same page... I believe that accessing "Appearances" or "Change Desktop Background" causes the fonts become correct. Becoming "tiny" is the right behavior. It is the extremely large font which is wrong. In my bug (496703), which was marked as a duplicate, I tried to make this clear.
Created attachment 341959 [details] typescript http://david.woodhou.se/wtf2.html
Retested with new gnome-settings-daemon from rawhide but problem still exists. gnome-settings-daemon-2.26.1-3.fc11
Retested with new gnome-settings-daemon from rawhide but problem is still not fixed. gnome-settings-daemon-2.26.1-4.fc11
Will this be fixed before F11 GM? My wife would like to switch from the Redmond OS to Linux but this bug will be a very annoying user experience.
Do you guys use dual-head (eg. external non-mirrored display)? Does setting the dpi to say 96 in /desktop/gnome/font_rendering/dpi fix the problem? If so, it's a dupe of bug 470462
No dual-head here. Setting the dpi to 96 in gconf-editor immediately triggers the "problem". Despite the fact that it xdpyinfo was reporting 96x96 dpi before anyway. I don't see how to return that gconf key to its previous '<no value>' state using gconf-editor...
After setting dpi to 96, other changes didn't seem to make any difference. I deleted the gconf key and restarted X, and things are working properly again... until/unless I run a config tool.
David, there's an 'Unset' menuitem in the context menu in gconf-editor.
I used 'unset' but that just deletes the key completely. The previous state that it was present, but had a special state '<no value>'. It's in that state again now. Using 'Unset' again deletes it completely, and makes my fonts go tiny again. /me goes to restart X again.
Bastien, No I don't use dual-head but setting the key to 96x96 fixes my problem. At first, setting the value killed my Gnome-Do docky panel, but it was fine after reboot.
After some experimentation, I've found that setting the dpi gconf key to 132 makes it look like it did before. Now I can start config tools without everything changing. [dwmw2@macbook ~]$ grep DPI /var/log/Xorg.0.log (**) NOUVEAU(0): DPI set to (263, 132) [dwmw2@macbook ~]$ xdpyinfo | grep inch resolution: 96x96 dots per inch
Probably caused by http://cgit.freedesktop.org/xorg/xserver/commit/?id=fff00df94d7ebd18a8e24537ec96073717375a3f The X server went back to its old behaviour of lying to us about DPI.
Without the gconf key set, when I first log into the system something manages to get the DPI right despite the X server lying to us: [dwmw2@macbook ~]$ xrdb -query | grep dpi Xft.dpi: 132.7021484375 When I first start the appearance applet, it gets reset to the value that the X server is giving us: [dwmw2@macbook ~]$ xrdb -query | grep dpi Xft.dpi: 95.923828125 When this happens, the gconf key is created, and gconf-editor shows '<no value>' for it. Setting the gconf key to 132 seems to make it work reliably at all times.
I can reproduce what you see now, by lying in xorg.conf (Adding a wrong DisplaySize to the monitor section) session starts out using the correct dpi, but xdpyinfo shows the wrong value opening the appearance capplet makes the wrong value take effect
I don't think the X server is to blame here, bug 470462 is the exact same symptoms, but happens on F9 which didn't have that X server change. The code in the control-center to change the DPI looks highly suspect to me, and I don't understand why it would even live there, instead of say, in gnome-settings-daemon's xrandr code, which knows about screens. And it would break with 2 screens anyway, as the dpi is likely to be different.
David could I get /var/log/xorg.conf, please?
David could I get /var/log/Xorg.0.log, please?
Created attachment 343189 [details] xorg.conf
control-center-2.26.0-7.fc11 might improve the situation somewhat. The dpi jump should now only happen if you actually open the font details dialog.
If you could try this build, that would be great: http://koji.fedoraproject.org/koji/buildinfo?buildID=101500
This is probably already realized but just in case not... This BZ also affects OpenOffice. In my case, the fonts were so large that navigating some of the OO dialog boxes was quite difficult.
Is there any chance of this being fixed before GM?
Retested with the latest xorg updates from rawhide to day and the problem is still not fixed.
Manually setting the dpi to 96x96 is not an acceptable workaround. This cause all of the K3B dialog text to be completely unreadable.
The chances of this getting fixed would be greater if somebody did what I asked for in comment 25
(In reply to comment #30) > The chances of this getting fixed would be greater if somebody did what I asked > for in comment 25 Sorry, I updated to that version and then forgot to report back. I do not believe I have noticed the font sizes/DPI "jumping" since the control-center-2.26.0-7.fc11 release. Thanks!
Matthias, Sorry. I didn't test on account of comment #20 and also my observation that Firefox and OO.org are affected--which are not gnome/gtk. I have now tested them and it _did not work_. It actually made things worse. I used to be able to open the Themes or Display Settings appellate and the fonts would shrink to their correct size (at least gtk applications). Now, all of my fonts are stuck at large font (looks like 16 or 18) instead of 10. David W, You're experience is completely _opposite_ of mine. I think the "all my fonts suddenly go tiny" is the correct behaviour (what is your screen resolution?). The default font in something like 10 or 12 point font which will look really small on high resolution configurations. Bryan
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command yum upgrade --enablerepo='*-updates-testing' Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD . Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
There is still brokenness here. In F-12 now, VMware crashed and took all my shift and ctrl keys with it. I discovered that reloading the keyboard configuration would fix it -- changing to a US keyboard and then back. At some point when I was doing that, all my fonts went huge again. Then most of them recovered, except xchat's (which I restarted) and nautilus, on the desktop background right-click menu.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.