Okay, let me explain the situation here as this bug might not get triggered on most systems. I was recently preparing a patch for Xfce4-settings to apply a distribution (Frugalware) specific patch that sets the Xft DPI to 72, Hinting, Icontheme, GTK Theme etc.

Looking at the source code, i found that xfsettingsd sets the initial Xft/DPI value to -1. And then it gets the DPI from X doing some calculation. So, in order to have a custom DPI by default, i changed the line 250 in xfsettingsd/registry.c from

    g_value_set_int (&properties[XSETTING_ENTRY_XFT_DPI].value, -1);

to

    g_value_set_int (&properties[XSETTING_ENTRY_XFT_DPI].value, 72);

And then i installed the new (patched) xfce4-settings package, created a new user and started Xfce. I noticed that the fonts were exteremly large (three-four alphabets covering the entire screen). So i ran the following command to see if the DPI had really changed to 72.


$ xfconf-query -c xsettings -p /Xft/DPI
73728

73728 ?!?!!? yeah, that's exactly 72*1024.

So, i checked the source code to see if anything else is resetting the dpi and i found this (again in xfsettingsd/registry.c line 540):

  if (strcmp (entry->name, "Xft/DPI") == 0 && g_value_get_int(&entry->value) != -1)
      *(CARD32 *)pos = g_value_get_int(&entry->value) * 1024;
  else
      *(CARD32 *)pos = g_value_get_int(&entry->value);


Here, it checks only if the value of Xft/DPI is NOT -1 which will evaluate to true (because its 72) and so it sets the dpi to 72*1024 and that's 73728 

IMO the comparison should be changed somehow to work with default dpi values > -1.


I hope you understood ;)

Thanks.