SDL_GetDisplayContentScale() reports the wrong value in a KDE session if xdg-desktop-portal-gnome is installed

[lostgoat]

When steam starts, we query the equivalent of SDL_GetDisplayContentScale( SDL_GetPrimaryDisplay() );. On some systems this is returning 1.0f even though in KDE settings the primary display is configured to use 125% scale.

This value comes from the reply = ReadDBusSetting(dbus, SCALE_FACTOR_KEY)) query in SDL. Which is returning 1.0. This matches what I see from a commandline query of this setting:

[andres@andres-dev ~]$ qdbus org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Settings.Read org.gnome.desktop.interface text-scaling-factor
1

If I uninstall xdg-desktop-portal-gnome and reboot, this results in SDL returning the correct data. In this case, SDL falls back to the Xft.dpi path and correctly returns 1.25.

I seem to recall from some conversations with gnome devs that text-scaling-factor is deprecated and no longer in use . But KDE was still updating this setting as a "compatibility" thing when the user interacted with KDE settings. That no longer seems to be the case (maybe this is no longer the case when under a wayland session?).

I'm not sure what the right path is towards fixing this atm, I've asked the relevant DE devs to leave their input here. I'm suspecting we need to ignore the value if running under a non-gnome session. Or possibly remove this query altogether if gnome isn't using this setting anymore either. I'm going to forward this issue to the relevant DE contributors to get their feedback.

[ebassi]

(With my GTK and GNOME hats on)

text-scaling-factor is the GNOME equivalent of the Xft.dpi Xrdb setting that KDE uses to provide fractional scaling: it is a scaling factor applied to the DPI when rendering text.

I seem to recall from some conversations with gnome devs that text-scaling-factor is deprecated and no longer in use .

That's incorrect: text-scaling-factor is still in use as an accessibility configuration, and some people still use it as a way to get fractional scaling on X11 as well, as X11 only allows integer scaling factors.

[lostgoat]

@ebassi thanks for the correction. That makes sense, and it is a good reason to keep the text-scaling-factor query.

The complicated part is that when both portals are installed in one system, we incorrectly get the gnome data while in the KDE session. And text-scaling-factor takes precedence over everything else. Is there some other data we could query from the portal to know if this setting is applicable for the current session?

If not, should we be guarding this query with a check in SDL with something like XDG_CURRENT_DESKTOP == GNOME?

This reply assumes that text-scaling-factor is not applicable in the KDE session. Which seems to be the case from my current observations. But waiting from KDE devs to confirm.

[davidedmundson]

This reply assumes that text-scaling-factor is not applicable in the KDE session.

That's complex, the whole situation is quite a mess of us setting things to work round toolkits and toolkits working round desktops. In KDE:

• On an X11 session we set BOTH xrdp.dpi and GTK text-scaling-factor to the same value. This is because some toolkits use only one or the other.

• On Wayland, we explicitly set GTK's text-scaling-factor to 1, because we're also setting the wayland scale and some certain toolkits apply both.

A check of the current desktop should work. I believe everyone else sets the Xrdp dpi as that's the more historic version.

[ebassi]

So, to summarise the expectations of GTK/GNOME:

• text-scaling-factor is an additional setting that is applied to text only on top of the window scaling factor
• it's important that the text scaling factor is not updated as a side effect of the window scaling factor, to avoid the double accounting; the text scaling should only be set by the user that wishes the text to be larger/smaller regardless of the window scaling factor
• ideally, text-scaling-factor should only be used when XDG_CURRENT_DESKTOP is gnome, as it's only ever relevant is when GNOME sets it; in theory, it could be used by something else, but given that it exists in the "GNOME" settings any outside consumers of that setting are entering into untested/unsupported territory

Having SDL do:

dpi = get_dpi()
if (gnome)
  dpi *= get_text_scaling_factor()

is probably the most correct solution in the overall matrix of supported configuration.

[Kontrabant]

GNOME seems to set the xft.dpi setting to a combination of the text-scaling-factor and the window scale, so a window scale of 100% and a text scale of 1.5 will report 144, and a window scale of 200% and a text scale of 1.5 results in xft.dpi reporting 288. Multiplying the xft.dpi scale value by the text scale would result in things being double-scaled.

Would it be best to just favor the xft.dpi value, even on GNOME, as it takes both window scale and text scale into account?

[ebassi]

GNOME seems to set the xft.dpi setting to a combination of the text-scaling-factor and the window scale

I've just checked, and the GNOME settings daemon indeed uses a mix:

• Gdk/WindowScalingFactor maps to the window scaling factor
• Gdk/UscaledDPI maps to the fallback DPI value of 96 multiplied by the text scaling factor
• Xft/DPI maps to Gdk/UnscaledDPI multiplied by the window scaling factor

Would it be best to just favor the xft.dpi value, even on GNOME, as it takes both window scale and text scale into account?

Yes, that would be the correct solution.

[ebassi]

Removing the text-scaling-factor check would lead to a lot of DBus-related code, which is kind of a win; but it also interact with the settings portal and it'll probably need a good testing campaign. Since this is X11, poking at the XSETTINGS is likely going to be the best option anyway.

[lostgoat]

This works correctly for me in KDE+Xwayalnd and KDE+X11.

@ebassi Can you let know if this worked okay for you in both session types in gnome? If so, I think this should be good to merge.