Do you mean gnome-settings-daemon?

Federico, is there any reason we hardcode this?

There was a weird rationale from Owen Taylor; let me dig it up...

I doubt that Gnome does hardcode it. Gnome seems to ask the Xserver, which dpi setting to use during the first start of your GNOME session. I'm sure about this, because I had "DisplaySize 16 16" in my xorg.conf due to another bug and GNOME uses the according dpi value, which of course looked comletely weird. I think I tested this with Beta1. Not sure. Maybe it was Alpha5+. But I can check it again. gconf needs to be killed and the ~/.gconf directory removed
before setting DisplaySize in xorg.conf and restarting GNOME session.

Is it still true that it is hardcoded?  Stefan Dirsch (CC:) installed 10.2 Beta1 recently on a test machine where the monitor was not correctly detected. /etc/X11/xorg.conf contained      DisplaySize 16 16  in the "Monitor" section after the installation which is of course hideously wrong.  The fonts in the login screen of gdm were *huge* because of this, it was barely possible to log in. And after logging in, all fonts in the Gnome desktop were *huge* as well.  If Gnome had hardcoded 96 dpi, this wouldn't have happened.  I don't want to say that hardcoding were a good idea. I just have the impression that it isn't hardcoded at the moment.  Apparently gconfd uses the dpi it can get from the X-server. But it seems to get the dpi from the X-server only once and then remember it. That means even if you notice the problem and fix "DisplaySize" in /etc/X11/xorg.conf to contain the correct values, the font size in Gnome will stay wrong. To fix the problem for Gnome as well after fixing it in /etc/X11/xorg.conf, one has to kill gconfd and delete the dpi entry in ~/.gconf (or just rm -rf ~/.gconf* to make sure).

I suspect the theory behind this is that in stock X there's no GUI way to change the DPI value, so GNOME provides an override in case your X config is wrong (under the theory that you're not likely to figure out how to fix it in xorg.conf if you didn't get it right in the first place). Since SUSE does provide a GUI way to change X's value, the argument falls apart a little (although the GNOME setting has the advantage that you don't need to restart X after changing it).

Dan, this is the answer to which question?

sorry, that's in answer to "why does GNOME have this setting at all rather than just always using the setting from xorg.conf?"

But you can see in comments #4 and #5 that gconfd *does* use the Xserver settings. At least initially.

Federico, can you answer, please?

I don't know the whole code, but here are some data points:

1. gnome-settings-daemon queries the configuration value stored in GConf for "/desktop/gnome/font_rendering/dpi".  It then propagates this value using the XSETTINGS protocol (on the "Xft/DPI" property), and also sets the "Xft.dpi" Xresource for apps which may want to use it (GNOME doesn't use that one).

2. The default value for /desktop/gnome/font_rendering/dpi in the GConf schema is 96.

3. GTK+ apps query the XSETTINGS manager for the "Xft/DPI property", and set this as the GdkScreen's resolution.  If an XSETTINGS manager is not running, GdkScreen uses the magic value of -1 for the resolution.

4. GtkWidget queries GdkScreen for the resolution, and sets that value on the Pango font rendering context.

5. Pango sees the resolution set in the context; if it is -1 (unset), it uses a fallback value of 96 DPI.  This is what gets used for rendering.

The rationale is as Dan says.  X servers don't provide correct DPI information in an uncomfortably large percentage of cases, so GNOME ignores that and a) provides a reasonable default value; b) lets the user change it easily.

We can put a trivial patch in control-center2 to keep the Xft.dpi Xresource from being set in gnome-settings-daemon (as a quick hack to address the original comment).

The root of the problem is that the X server does not provide reasonable values.  If we could trust it, there would be no need for this setting at all :)

About comment #4:

GDM probably picks up the values from xorg.conf because there's no XSETTINGS manager running at that point, although I don't know why my point (5) wouldn't apply there.

About comment #5:

I don't know why you got those weird fonts in your desktop.  Was gnome-settings-daemon running?  If not, why did it crash [that would be a bad bug]?  I also don't know why my point (5) wouldn't apply.

You can try seeing what resolution values get passed around in the functions in pangocairo-fcfontmap.c.

This can't be a critical bug, BTW, unless you make it for the X server about providing broken DPI values.

Also:  I don't know of any code in GNOME that actually queries the X server for the DPI value.

Dan, any chance to convince you to give it simply a try reproducing the issue? All that you need to do would be adding a fresh user and adding a line

  DisplaySize  16 16

to monitor section of your xorg.conf. This should at least break completely
the font sizes for the (Gnome) Xsession of the new user. Not sure if this 
will also break gdm itself, but I think so.

Retitling for clarity.

I'm going to add code to gnome-settings-daemon to detect totally broken DPI settings and use a default value (96 DPI).

See also bug #219801, which is about X servers which get DisplaySize wrong.

BUT... why on *earth* does /usr/bin/gnome:

1. use a horrible sed script to extract the resolution from 'xdpyinfo'
2. *overwrite* your gconf key for the DPI!?

(In reply to comment #16)
> BUT... why on *earth* does /usr/bin/gnome:
> 
> 1. use a horrible sed script to extract the resolution from 'xdpyinfo'
> 2. *overwrite* your gconf key for the DPI!?

Sigh, that came from the fix for bug #171096.

I'm going to remove that chunk from /usr/bin/gnome (gnome-session package).  Then I'm going to make gnome-settings-daemon see if the DPI value provided by X is reasonable, and if not to pick a reasonable default.  This will be used unless the user has set an explicit DPI value in gnome-font-properties.

Thanks. could you outline the exact algorithm so that we can make sure that the same (!) is done in KDE (to avoid that we have conflict in font sizes for users that use applications from both environments). 

(In reply to comment #18)
> Thanks. could you outline the exact algorithm so that we can make sure that the
> same (!) is done in KDE (to avoid that we have conflict in font sizes for users
> that use applications from both environments). 

Sure!  What I'm using is in the next attachment.

Created attachment 106649 [details]
dpi.c

This is what I'm using in gnome-settings daemon.  You want to look at get_dpi_from_gconf_or_x_server().  First, I see if the DPI value is set in GConf; if so, this means that we should use the user's preference.  If not, I compute the DPI from the screen's dimensions and then use a fallback value if it is outside a valid range.

Dirk, I'm not sure what to do about GTK+ apps being run under a KDE session.  Do you have an XSETTINGS manager like gnome-settings-daemon which sets the "Xft.dpi" setting?  [Note that this has nothing to do with Xresources]

If there is an XSETTINGS manager, GTK+ apps should have no problems; they just pick up that value.  Otherwise, I don't know where to pick up KDE's DPI setting; do you know how?

Created attachment 106652 [details]
Updated /usr/bin/gnome script

This is what I'll put in our gnome-session package.  It is the same as the old script, minus the part that overwrites the user's GConf key for DPI.

Created attachment 106653 [details]
control-center2-217790-sanitize-dpi.diff

This is the patch I'll use for our control-center2 package.

See http://bugzilla.gnome.org/show_bug.cgi?id=378338 for the bug upstream.

Packages for testing are here:
http://w3.suse.de/~federico/dpi-fixes/

See bug #168189 for the corresponding bug in GDM.

Couldn't we close this one now? Which issues are still open, Dirk?

(In reply to comment #27)
> Couldn't we close this one now? Which issues are still open, Dirk?

Uh, please don't close the bug.  We'll likely ship a hotfix with the patch to gnome-session and to control-center2.  I'd like to keep the bug open until that happens; otherwise I'll forget about those patches :)

*** Bug 221494 has been marked as a duplicate of this bug. ***

BTW, I submitted the fixes for control-center2 and gnome-session for SLED 10 SP1.

Submitted gnome-session to STABLE:

* Fri Dec 22 2006 - federico@novell.com
- Removed the part of /usr/bin/gnome that overwrites the
  /desktop/gnome/font_rendering/dpi setting in GConf upon the user's
  first login.  With an updated control-center2 package,
  gnome-settings-daemon will take care of figuring out the right DPI
  value.  Fixes the gnome-session part of
  https://bugzilla.novell.com/show_bug.cgi?id=217790.


Submitted control-center2 to STABLE:

* Fri Dec 22 2006 - federico@novell.com
- Added control-center2-217790-sanitize-dpi.diff to fix the
  control-center2 part of
  https://bugzilla.novell.com/show_bug.cgi?id=217790.  Some X servers
  don't report the screen's physical dimensions correctly, so the DPI
  value is wrong.  This can lead to unusably huge or tiny fonts.  This
  patch constrains the X server's DPI value to something reasonable.

Not sure if it's relevant to this bug, but I just installed openSUSE from Factory with GNOME. The text size was indeed very big. The DPI setting in GConf was set to 96. After chaning the value to something else, and then back to 96 my fonts finally got the "right" size, ie smaller.