We recently received new laptops with a 2160p display. I received it with Ubuntu 16.04 installed with the Unity desktop. I've since installed and use Xfce 4, but kept the Unity greeter (because pretty).

I fully expected to see font scaling issues with the high-DPI display, but something has set the Xresource Xft.dpi to 192, rather than the typical 96. This is picked up by nearly all applications, making the internal display mostly usable. 10 out of 10, right?

Well, no, because I can't figure out where this is being set. Xfce's appearance panel claims the DPI is 96. dconf variables where they exist also show 96. xdpyinfo also says it's 96. Xorg.0.log has one message regarding DPI, and says it's 96. lightdm.conf (configuration file for the Unity greeter) shows no attempt to change it. And xrandr is reporting an identity transformation matrix (no scaling).

My suspicion is that either GNOME or the Unity greeter are the culprit, since the greeter starts out rendered in Flyspeck 3, but then rescales itself after a moment. But I can't figure out where it was told to do this, or how it persists to the desktop session.

My goal is to plug in an external 1080p display and tweak the DPI such that both displays are vaguely legible. But I can't effectively do that if I'm fighting with something else trying to do it behind my back.

All clues welcome.

System Info

  • Ubuntu 16.04.3
  • unity 7.4.0+16.04.20160906-0ubuntu1
  • xorg 1:7.7+13ubuntu3
  • xfce 4.12.2
  • 1
    X resources live in the X server and stay set until the server exits. So if the greeter does it, it's going to stay for the desktop session. Of course, you could use xrdb to change it. (Not an answer, as presumably there is some much better way). BTW: isn't it Xft.dpi, with a period, not a colon? Also curious why this is making the display unusable!
    – derobert
    Aug 30, 2017 at 21:00
  • Xft.dpi is correct; edited to fix. And no, it's not making the display unusable -- quite the opposite, in fact. But if I want to fiddle with it, I need to know what's applying it in the first place, and why every other place to look for DPI settings is saying it's 96.
    – ewhac
    Aug 30, 2017 at 21:13
  • I would guess it comes from the physical size reported by, e.g., xrandr, which should come from the monitor's EDID (which you can get from xrandr --prop)
    – derobert
    Aug 30, 2017 at 22:00
  • 1
    I'm having this problem with no desktop environment. I have Xft.dpi: 192 in .Xdefaults, but someone unknown to me is changing it to 96 (as reported by xrdb -query). I can't figure out when this happens, I only find out when I restart my window manager and the titles come up tiny. FWIW xdyinfo reports a resolution of 192x194 (sic). I guess I'll just run xrdb -query in a loop and have my shell bring up a dialog when the value changes. Sep 20, 2018 at 19:05

3 Answers 3


I believe the underlying reason why this problem exists can be gleaned from https://gitlab.freedesktop.org/xorg/xserver/-/issues/509 and https://bugzilla.gnome.org/show_bug.cgi?id=757142.

GTK in v3.17 imposed Xft.dpi: 96 in environments where Xft.dpi is unneeded and otherwise null. Gnome developers refused to revert the imposition, and Xorg developers are loath to provide a workaround for Gnome's imposition.

*SUSE developers wisely reverted the imposition shortly after I brought the issue to their attention. A switch to *SUSE or any distro that has done the same amounts to working around the imposition.

I believe Debian (running TDE & IceWM at least) and Ubuntu (running TDE & IceWM at least) have done it too, so possibly there are other distros. Mint (running XFCE at least) apparently has not, and for sure Fedora has not, as it was Gnome's flagship was among the first if not the first to switch to 3.17. In short, I believe the answer to who is doing the setting at the most basic level is buried in gdk/x11/gdkxftdefaults.c.


Apparently Gnome-settings-daemon changes Xft.dpi.

I execute this as /usr/lib/gsd-xsettings from ~/.xinitrc. I don't use Gnome but I need to configure various GTK apps to e.g. not blink the cursor, and that's why I run the daemon. (I could also edit ~/.config/gtk-3.0/settings.ini)

I just changed that so I run xrdb after starting the settings daemon.

I'm probably not understanding some of the terminology of the question but maybe this will be useful. I imagine that one of the pieces of software you are running is executing gsd-xsettings.

Here is the piece of code which changes the Xft.dpi property:

$ grep -n Xft.dpi gnome-settings-daemon/plugins/xsettings/gsd-xsettings-manager.c -2
852-        g_debug("xft_settings_set_xresources: orig res '%s'", add_string->str);
854:        update_property (add_string, "Xft.dpi",
855-                                g_ascii_dtostr (dpibuf, sizeof (dpibuf), (double) settings->scaled_dpi / 1024.0));
856-        update_property (add_string, "Xft.antialias",

The top of that file explains at great length why the software defaults to 96 DPI. Presumably I could configure something to set an XSETTINGS value for "Xft/DPI", and then GTK would be using the value I prefer, rather than overriding the value I configured in ~/.Xdefaults with its "default" of 96.


I have this partially figured out. @derobert was correct; the setting is left over from the Unity greeter.

I created two dummy user accounts to experiment with. The Unity greeter starts out at 96 DPI, then redraws itself at 192 DPI. With one freshly-created dummy user, I logged in to a Unity session. The desktop immediately flipped back to 96 DPI. The various control panels also reported 96 DPI. So Unity appears to force the setting.

With the other dummy user, I logged in to an Xfce session. All the control panels reported 96 DPI. However, the DPI reported by xrdb -query -- and used by all the running programs -- remained at 192, presumably left over from the Unity greeter. But the instant I modified the DPI setting in Xfce's Appearance control panel, the entire desktop flipped to that DPI value and stayed there. My guess is that until you touch the DPI value, the setting is not in the user's xfconf variables, and if it's not present then it doesn't explicitly get set at login.

So it looks like Xfce has a bug -- either for not checking the current value of Xft.dpi at startup, or for not forcing it to an expected default.

I still haven't figured out why the Unity greeter is switching to 192 DPI in the first place.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .