Bug 496531 - Fonts change when config tool starts
Summary: Fonts change when config tool starts
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 496703 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-20 00:23 UTC by David Woodhouse
Modified: 2018-04-11 13:31 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-06-28 12:05:59 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
typescript (55.24 KB, text/plain)
2009-04-30 16:57 UTC, David Woodhouse
no flags Details
xorg.conf (676 bytes, patch)
2009-05-08 22:38 UTC, David Woodhouse
no flags Details | Diff

Description David Woodhouse 2009-04-20 00:23:59 UTC
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.)

Comment 1 Matthias Clasen 2009-04-20 23:57:04 UTC
*** Bug 496703 has been marked as a duplicate of this bug. ***

Comment 2 Bastien Nocera 2009-04-22 16:36:44 UTC
(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.

Comment 3 David Woodhouse 2009-04-22 18:35:44 UTC
gnome-settings-daemon _was_ running before I did this. And is still running, with the same PID, after the fonts go tiny.

Comment 4 Bastien Nocera 2009-04-30 10:11:29 UTC
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.

Comment 5 Bryan Christ 2009-04-30 14:31:30 UTC
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.

Comment 6 David Woodhouse 2009-04-30 16:57:05 UTC
Created attachment 341959 [details]
typescript

http://david.woodhou.se/wtf2.html

Comment 7 Bryan Christ 2009-05-01 14:36:41 UTC
Retested with new gnome-settings-daemon from rawhide but problem still exists.
gnome-settings-daemon-2.26.1-3.fc11

Comment 8 Bryan Christ 2009-05-07 14:59:25 UTC
Retested with new gnome-settings-daemon from rawhide but problem is still not fixed.
gnome-settings-daemon-2.26.1-4.fc11

Comment 9 Bryan Christ 2009-05-07 15:01:24 UTC
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.

Comment 10 Bastien Nocera 2009-05-08 03:12:56 UTC
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

Comment 11 David Woodhouse 2009-05-08 13:34:36 UTC
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...

Comment 12 David Woodhouse 2009-05-08 13:48:50 UTC
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.

Comment 13 Matthias Clasen 2009-05-08 14:24:36 UTC
David, there's an 'Unset' menuitem in the context menu in gconf-editor.

Comment 14 David Woodhouse 2009-05-08 14:33:12 UTC
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.

Comment 15 Bryan Christ 2009-05-08 14:48:45 UTC
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.

Comment 16 David Woodhouse 2009-05-08 14:49:46 UTC
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

Comment 17 David Woodhouse 2009-05-08 15:08:43 UTC
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.

Comment 18 David Woodhouse 2009-05-08 15:34:26 UTC
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.

Comment 19 Matthias Clasen 2009-05-08 15:55:01 UTC
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

Comment 20 Bastien Nocera 2009-05-08 17:52:24 UTC
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.

Comment 21 Matěj Cepl 2009-05-08 21:14:47 UTC
David could I get /var/log/xorg.conf, please?

Comment 22 Matěj Cepl 2009-05-08 21:15:12 UTC
David could I get /var/log/Xorg.0.log, please?

Comment 23 David Woodhouse 2009-05-08 22:38:38 UTC
Created attachment 343189 [details]
xorg.conf

Comment 24 Matthias Clasen 2009-05-09 13:35:45 UTC
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.

Comment 25 Matthias Clasen 2009-05-09 15:43:00 UTC
If you could try this build, that would be great:

http://koji.fedoraproject.org/koji/buildinfo?buildID=101500

Comment 26 Bryan Christ 2009-05-12 21:33:44 UTC
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.

Comment 27 Bryan Christ 2009-05-19 16:05:22 UTC
Is there any chance of this being fixed before GM?

Comment 28 Bryan Christ 2009-05-20 15:05:02 UTC
Retested with the latest xorg updates from rawhide to day and the problem is still not fixed.

Comment 29 Bryan Christ 2009-05-20 20:22:06 UTC
Manually setting the dpi to 96x96 is not an acceptable workaround.  This cause all of the K3B dialog text to be completely unreadable.

Comment 30 Matthias Clasen 2009-05-23 03:22:44 UTC
The chances of this getting fixed would be greater if somebody did what I asked for in comment 25

Comment 31 Sean E. Millichamp 2009-05-23 11:10:28 UTC
(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!

Comment 32 Bryan Christ 2009-05-26 15:27:40 UTC
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

Comment 33 Bug Zapper 2009-06-09 14:09:34 UTC
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

Comment 34 Matěj Cepl 2009-11-05 18:26:57 UTC
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.]

Comment 35 David Woodhouse 2009-11-05 19:00:12 UTC
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.

Comment 36 Bug Zapper 2010-04-27 13:47:18 UTC
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

Comment 37 Bug Zapper 2010-06-28 12:05:59 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.