Font DPI in kde should be set to 96 by default, but it's calculated automatically which causes issues


I use tumbleweed with kde and nvidia with the proprietary driver.

I’ve been searching for a solution to my problem (Smaller font than usual in firefox address bar (doesn't happen at all times)) for over two months and finally found it. I’ve had to set font dpi manually to 96 for proper font sizes.

Now that I’ve discovered that, why is the font dpi calculated automatically on tumbleweed nowadays? I saw something in the arch wiki that some time ago it was changed to automatically set the dpi, but it was reverted later on as it caused issues. But currently in tumbleweed the output of

xdpyinfo | grep resolution

shows something like 92x91 on a 24 inch 1920x1080 screen. It should be 96x96.

I don’t know why system calculates the dpi automatically, but I think it should be changed to default to 96 when additional scaling isn’t used.

@piotrus3g Hi, I’m on TW/GNOME here with Nvidia and all fine DPI wise.

Perhaps a read here?

I have three (24" 1920x1080) screens here and see;

xdpyinfo | grep -B1 dot

  dimensions:    3840x2160 pixels (1016x572 millimeters)
  resolution:    96x96 dots per inch

So what did you have to do to set the DPI?

I’m on kde so it could be different from gnome. To set the dpi I used the option to force font dpi in kde font settings gui, but I’ve also set additionally in the nvidia settings generated xorg.conf file just in case. Now everything is fine (so far at least).

1 Like

Actually it should not. It’s an old, old convention with a lot of history:

This convention eventually caused:

among other problems related to DPI. Later it caused W3 to remove from standards for web browsers the ability to use traditional point sizes, making it impossible to render accurate physical sizes in web browsers that conform to standards. 99+% of the time when 96x96 is shown for resolution it is this arbitrary convention being employed. Some display devices are in fact close to 96, but it’s not common, depending on your definition of “close”. Since the advent of “high resolution” screens, variation in screen densities has mushroomed. 200 and above is common, while instances of less than 96 appear on the larger sizes of TVs employed as computer displays.

Not too long ago, FOSS X environments were briefly permitted to automatically calculate and apply accurate DPI, but it was quickly reverted. It’s my understanding as a non-user of them that NVidia’s proprietary drivers also permit applying accurate DPI.

Fonts for PCs were designed for the low physical resolution that 96 represents. Their competence is poor when DPI is less than 96, which has caused most web browsers to floor DPI at 96 so as to keep small sizes legible.

You say proprietary nvidia, but I remember having small firefox font right after the first boot when I didn’t have the official nvidia drivers installed yet. So it seems that the nouveau driver could also calculate screen dpi automatically. But if nouveau is managed by the community, not by nvidia, then shouldn’t constant dpi be used here?

Arch wiki says this about screen dpi

While you can set any dpi you like and applications using Qt and GTK will scale accordingly, it is recommended to set it to 96, 120 (25% higher), 144 (50% higher), 168 (75% higher), 192 (100% higher) etc., to reduce scaling artifacts to GUIs that use bitmaps. Reducing it below 96 dpi may not reduce the size of the GUIs graphical elements, as typically the lowest dpi the icons are made for is 96.

I remember testing tumbleweed with xfce in a vm and in the system font configuration settings gui there was force font dpi set to 96 checked by default. If I understand correctly font dpi should be set to 96 without scaling as automatic calculation could cause various issues. My tumbleweed vm with kde has screen dpi set to 96 by default without me forcing it in the font settings, so it actually could be the default behavior for non nvidia users (or the driver for vm emulated graphics card sets it this way).

There’s history on this issue related to the switch from GTK2 to GTK3 in building Mozilla products:

openSUSE bug 1022830 – GTK3 apps not honoring system-wide DPI settings nor…
Gnome bug 757142 – [REGRESSION][BISECTED] Recent change breaks HiDPI setup based on…
Mageia bug 21201 [regression] GTK3 apps do not respect DE font sizes when Desktop DPI…
Mozilla bug 1269274 UI text sizes no longer inherited from Linux system
Fedora bug 1420743 96DPI Gecko browsers no longer utilize KDE’s desktop font…

Among them are several screenshots I attached. The possible workarounds I apply/utilize in Leap and TW are long forgotten, either buried in profiles somewhere, or a distro-specific application of the bug 757142 reversion patch in openSUSE products.

The original cause:
Gnome/GTK patch

xrdb -query | grep dpi will show whether Xft.dpi is set. To force it to 96 if it’s something else, add line Xft.dpi: 96 to your ~/.Xresources file. This is actually what DE scalers usually do, so if you have already set scaling via your DE, IIRC your DE will override .Xresources. Xft.dpi is independent of Xorg values shown by xdpyinfo | grep ution. If it isn’t 96, and you wish it to be, find where /usr/bin/Xorg is launched by your installation and append -dpi 96 or change an existing value. It’s the Xft.dpi setting that Mozilla products obey. It’s mostly old apps that use the Xorg/xdpyinfo value.

When I was looking for a way to set a constant dpi value the arch wiki mentioned something about the Xft.dpi. I looked for some X profile files in my system but there were actually none by default so I didn’t bother creating them as I was not sure how is the syntax. But the setting force font dpi in kde font settings gui sets the Xft.dpi value.