GNOME Bugzilla – Bug 757142
[REGRESSION][BISECTED] Recent change breaks HiDPI setup based on calculated or forced DPI
Last modified: 2017-10-17 14:52:39 UTC
After a recent GTK+ update, text in GTK+ applications such as the LightDM GTK+ greeter, Ghex, and menus in LibreOffice became tiny on a HiDPI setup. Manually bisecting the cause revealed that the breaking change was introduced between GTK+ versions 3.17.4 and 3.17.5, more precisely the following commit: Simplify Xft setting fallback : https://git.gnome.org/browse/gtk+/commit/?id=bdf0820c501437a2150d8ff0d5340246e713f73f Building GTK+ version 3.17.5 with this change reverted resolved the issue, text was again scaled according to custom DPI value. All testing was done on a host machine and in a VM with the following configuration: Host OS: Arch Linux x86_64 +multilib, using the proprietary NVIDIA X driver VM (Qemu) OS: idem /etc/X11/xorg.conf.d/90-local.conf: Section "Screen" Identifier "Screen 0" Monitor "HiDPI" EndSection Section "Monitor" Identifier "HiDPI" # For NVIDIA proprietary driver Option "UseEdidDpi" "false" Option "DPI" "160 x 160" # For VM #DisplaySize 304.8 171.4 # Reaching for 160 DPI EndSection GTK+ was compiled using the 'official' Arch Linux PKGBUILD for the gtk3 package, using the appropriate values for pkgver. The main problem with this change is that it eliminates the possibility of HiDPI setups working "out-of-the-box", with only minimal or automatic configuration done by the X server alone. Users using a HiDPI setup will now have to edit multiple configuration files to achieve the same result. Here is an example of the changes I've had to make to restore previous behaviour: - Keep the custom xorg.conf: to properly scale the i3 window manager and Qt applications. - Create /etc/X11/Xdefaults, adding "Xft.dpi=160": to properly scale GTK+ apps in X user sessions. - Edit /etc/lightdm/lightdm-gtk-greeter.conf, uncommenting and changing "xft-dpi=160": to properly scale LightDM's GTK+ greeter (login manager). All of this, combined with the possibility of discrepancies between (calculated) DPI values and screen sizes in X server logs, output from `xdpyinfo` and `xrandr`, and the forced default 96 DPI set by GTK+ when no "Xft.dpi" is configured, doesn't make for a better troubleshooting experience, it actually makes it worse, IMHO.
Correction: - Keep the custom xorg.conf: to properly scale the i3 window manager{, GTK 2} and Qt applications.
Correction 2: - Create /etc/X11/Xdefaults, adding {"Xft.dpi: 160"}: to properly scale GTK+ apps in X user sessions.
> Users using a HiDPI setup will now have to edit multiple configuration files > to achieve the same result. I don't consider this a serious problem. Once you are editing files in /etc/X11 manually, all bets are off anyway.
(In reply to Matthias Clasen from comment #3) > > Users using a HiDPI setup will now have to edit multiple configuration files > > to achieve the same result. > > I don't consider this a serious problem. Once you are editing files in > /etc/X11 manually, all bets are off anyway. I don't understand the relevance of your comment. Quoting myself: "it eliminates the possibility of HiDPI setups working "out-of-the-box", with only minimal _or automatic configuration done by the X server alone_." This means that this change makes it impossible for the system to configure DPI automatically for a HiDPI setup, using only information obtained by the X server during its own autoconfiguration. No editing of configuration files, in /etc/X11 or otherwise, was ever needed for that, at least for reasonably modern versions of the X server. As a result of the change to GTK+, users who previously could rely on a minimal, autoconfigured system must now rely on some desktop environment, settings daemon, configuration tool or whatever to transform information which is _readily available_ from the X server into some arbitrary set of configuration files (or manually edit them) every time they change monitors , hook their system up to a projector, TV or whatever. The fact that users wishing to force a particular DPI valua will now have to edit more than their usual crop of config files merely adds to the already existing problem.
Yes. You need to have a properly configured system for software to work as intended. I think you're overstating the problem of going from "I have to edit /etc/X11/xorg.conf" to "I have to edit /etc/X11/xorg.conf and /etc/X11/Xdefaults"
Perhaps I didn't make myself clear, so I will try again: the main issue is that completely autoconfigured (_no_ config files touched) HiDPI setups will no longer work "out of the box", because the information provided by the X server gets ignored by GTK+. This is a regression, no matter how you slice it. Again, the change does not fix any bugs, nor does it add any new features, rather it takes away the user's choice to have the system autoconfigure the DPI value from information provided by the X server. It is also a major issue because it forces a policy decision on HiDPI users: to either stick with 96 DPI or to manually configure a different value. I haven't seen any discussion about this policy change or possible alternatives on any public forum or mailing list. My suggestion: back out the change and _document_ instead that users have at least two options for specifying DPI value: - Tinker with xorg.conf - Somehow merge a value for Xft.dpi into the X resources database (by editing ~/.Xdefaults, /etc/X11/Xdefaults or whatever). This suggestion leaves user freedom intact, and it also allows users to implement the policy (for whatever reason) by setting "Xft.dpi: 96". Win-win, IMHO.
Created attachment 333554 [details] 168 D{
Comment on attachment 333554 [details] 168 D{ If gtk depends on Xft.dpi for proper operation, it needs to generate it itself from the Plasma, KDE3 or TDE environment it has to live in. Up to 3.17.4, everything worked reasonably in Firefox and SeaMonkey UI even in the most recent alphas and betas built with GTK3, with Xft.dpi intentionally set null. DisplaySize in xorg.conf produces a DPI appropriate to the physics involved without the admin needing to dp more calculations than he already has. Same goes for fbmm with randr. The values are obviously there to use, so if gtk3 apps must look to Xft.dpi, then Xft.dpi must look to the DPI the server produced automatically.
Attachment 333554 [details] was supposed to have been described thus: 168 DPI Plasma5 screenshot comparing expected UI in GTK2 Firefox 45 to minuscule UI in GTK3 Firefox 47
Xorg enhancement request to work around this: https://bugs.freedesktop.org/show_bug.cgi?id=98909
Like many others, I am still affected by this bug, as any GTK+ application (most notably Firefox and LibreOffice) behaves incorrectly on properly configured X servers with HiDPI screens. The gravest thing is that the rationale for the change that introduced this regression completely escapes me. I would like to have least have a technical explanation of why this was needed in the first place. The situation of HiDPI on Linux is already bad enough as-is without any need to introduce additional, _unnecessary_ complexity. And this change does exactly that: introduces additional, _unnecessary_ complexity to ensure the correct behavior of GTK+ applications in HiDPI configurations. So a rationale for this change would be _much_ appreciated. Note that Xorg already by itself reports 96dpi unless explicitly configured differently, so the cases when by this change GTK+ uses a different DPI than reported by X are the following: 1. an Xorg explicitly configured to report a different DPI than 96; 2. an X server different from Xorg, explicitly configured to report a different DPI than 96; 3. an X server different from Xorg, that autodetects the monitor DPI and reports something different than 96. In the cases (1) and (2), by using a hardcoded 96 rather than the X-reported DPI value, GTK+ is _intentionally ignoring_ an explicit DPI setting. Why? In the case (3) GTK+ is still _intentionally ignoring_ the X-reported DPI setting. Why?
Created attachment 344123 [details] [review] Patch reverting the problematic commit Here is a patch reverting the problematic commit.
Note too that "config files" *were* not the only route to having configured a logical display density that matches device density, or *any* logical density desired. Previously, 'xrandr --dpi 160' in a startup script was sufficient for X sessions and all X apps to experience 160 DPI, as well as for apps started subsequent to running xrandr after a session is already running. Since GTK 3.17.5, these results are no longer possible for apps built with the GTK3 toolkit: e.g. mozilla.org-built apps such as Firefox, Firefox ESR and SeaMonkey: https://bugzilla.mozilla.org/show_bug.cgi?id=1269274