X11: Fix content scale fallback value on KDE

KDE sometimes removes the Xft.dpi resource when it would be set to the
X11 default value of 96, causing GLFW to fall back to a value calculated
from the core display sizes in pixels and mm in a desktop environment
that supports Xft.dpi.

This moves to a hardcoded fallback value of 96 on the assumption that
there are more people running KDE with 96 DPI than there are people
running desktop environments that do not support Xft.dpi.

All of this is terrible please send help.

Fixes #1578.

(cherry picked from commit 75294462b3)

README.md

@@ -133,6 +133,7 @@ information on what to include when reporting a bug.
  - [X11] Bugfix: Key names were not updated when the keyboard layout changed
    (#1462,#1528)
  - [X11] Bugfix: Decorations could not be enabled after window creation (#1566)
+ - [X11] Bugfix: Content scale fallback value could be inconsistent (#1578)
 
 
 ## Contact

src/x11_init.c

@@ -793,13 +793,10 @@ static GLFWbool initExtensions(void)
 //
 static void getSystemContentScale(float* xscale, float* yscale)
 {
-    // NOTE: Fall back to the display-wide DPI instead of RandR monitor DPI if
-    //       Xft.dpi retrieval below fails as we don't currently have an exact
-    //       policy for which monitor a window is considered to "be on"
-    float xdpi = DisplayWidth(_glfw.x11.display, _glfw.x11.screen) *
-        25.4f / DisplayWidthMM(_glfw.x11.display, _glfw.x11.screen);
-    float ydpi = DisplayHeight(_glfw.x11.display, _glfw.x11.screen) *
-        25.4f / DisplayHeightMM(_glfw.x11.display, _glfw.x11.screen);
+    // Start by assuming the default X11 DPI
+    // NOTE: Some desktop environments (KDE) may remove the Xft.dpi field when it
+    //       would be set to 96, so assume that is the case if we cannot find it
+    float xdpi = 96.f, ydpi = 96.f;
 
     // NOTE: Basing the scale on Xft.dpi where available should provide the most
     //       consistent user experience (matches Qt, Gtk, etc), although not