xsettings: Set Xft.dpi in X resources to scaled_dpi

[OleksandrChekhovskyi]

This makes it match Xft/DPI in XSETTINGS. Applications relying on Xft.dpi on HiDPI screens will now work correctly.

Behavior is now consistent with GNOME, relevant commits from gsd: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/047f030235972fdab5e15aff484006caf914216a https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/25c7cc703118c69b224acf9c4f7af09a31f50a34

[lukefromdc]

QT apps giving me some inconsistant behavior, due to their own implementation of hidpi support. Played with turning window-scaling-factor-qt-sync on and off (and restarting the session) and it seems that no setting gets icons, text, and padding right all at once. Best results were setting text size to 5px (rendered as 10) in qt5ct and keeping window-scaling-factor-qt-sync turned ON. Kdenlive looked best with it off and 10px text-except that gave icons half the expected size with mostly normal padding.That setting also made Audacious's (old-style not GTK) control window and equalizer render half-size. There too I had to reduce text size. Note that this is a very old app, a fork of XMMS which I first used 16 years ago

[OleksandrChekhovskyi]

Qt5 HiDPI detection has been broken for me pretty much always (in GNOME also), so I have to keep this in the environment: QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCREEN_SCALE_FACTORS=2

Note that mate-settings-daemon currently sets QT_SCALE_FACTOR in scale_change_workarounds, and not QT_SCREEN_SCALE_FACTORS. QT_SCALE_FACTOR does not work properly for me, fonts get blown up to huge sizes, so it has to be QT_SCREEN_SCALE_FACTORS specifically. Maybe we should actually change this so that things work out of the box, at least until Qt5 HiDPI logic is fixed.

Without the fix in this patch, additional DPI override is required, like this for 2x screen: QT_FONT_DPI=192 (otherwise it uses Xft.dpi value).

[raveit65]

What means XFT ? Edit: got it, xfont.dpi Which applications can be used for testing?

[OleksandrChekhovskyi]

Xft.dpi in X resources is one of the (many) ways to get current font DPI. In terms of example applications, conky (as mentioned above in the comments already, when use_xft is on). glfw library uses it for content scale detection. There might be more examples, but these should be enough already to see the point.

[raveit65]

Ok, another application to test is git gui which scales perfectly now under HIDPI. All KDE application which i use have too big fonts now, see my list. plan keypassxc k3b flacon kaffeine mkvtoolnix simpleScreenRecorder soundkonverter But they scales fine when i disable QT_SCALE_FACTOR in

[rave@mother ~]$ gsettings get org.mate.interface window-scaling-factor-qt-sync
false

So i think it's better to disable the env QT_SCALE_FACTOR when this PR is merged.

Edit: In fedora conky works out of box with this PR

[raveit65]

Best results for all my KDE applications i got if using export QT_AUTO_SCREEN_SCALE_FACTOR=1 in my ~/.bash_profile

[OleksandrChekhovskyi]

Regarding Qt applications, here is my findings: (assuming this patch is applied already, and screen DPI is 240)

No QT_* environment variables - tiny fonts, broken paddings:

QT_AUTO_SCREEN_SCALE_FACTOR=1 - everything is now huge:

QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCREEN_SCALE_FACTORS=2 - seems alright:

The best result is achieved in the last case, so that's what I would recommend. In practice that would mean this additional change:

diff --git a/plugins/xsettings/msd-xsettings-manager.c b/plugins/xsettings/msd-xsettings-manager.c
index 5247523..36a7660 100644
--- a/plugins/xsettings/msd-xsettings-manager.c
+++ b/plugins/xsettings/msd-xsettings-manager.c
@@ -538,8 +538,8 @@ scale_change_workarounds (MateXSettingsManager *manager, int new_scale)
                                 g_warning ("There was a problem when setting QT_AUTO_SCREEN_SCALE_FACTOR=0: %s", error->message);
                                 g_clear_error (&error);
                         }
-                        if (!update_user_env_variable ("QT_SCALE_FACTOR", new_scale == 2 ? "2" : "1", &error)) {
-                                g_warning ("There was a problem when setting QT_SCALE_FACTOR=%d: %s", new_scale, error->message);
+                        if (!update_user_env_variable ("QT_SCREEN_SCALE_FACTORS", new_scale == 2 ? "2" : "1", &error)) {
+                                g_warning ("There was a problem when setting QT_SCREEN_SCALE_FACTORS=%d: %s", new_scale, error->message);
                                 g_clear_error (&error);
                         }
                 }

[raveit65]

QT_AUTO_SCREEN_SCALE_FACTOR=1 - everything is now huge:

Did you disable the workaround before testing?

[rave@mother ~]$ gsettings get org.mate.interface window-scaling-factor-qt-sync
false

[OleksandrChekhovskyi]

QT_AUTO_SCREEN_SCALE_FACTOR=1 - everything is now huge:

Did you disable the workaround before testing?

[rave@mother ~]$ gsettings get org.mate.interface window-scaling-factor-qt-sync
false

I have this setting disabled, and I also made sure there are no QT_* environment variables other then those I specified for each test.

[raveit65]

Than we have different results. In fedora 34 i have disabled org.mate.interface window-scaling-factor-qt-sync + export QT_AUTO_SCREEN_SCALE_FACTOR=1 in my ~/.bash_profile and QT applications are looking fine, eg. keepassxc

Any way. i will test your proposal.

[lukefromdc]

The ONLY thing that worked for me on Debian was to set QT_AUTO_SCREEN_SCALE_FACTOR=1 and I had to do it in mate-settings-daemon/plugins/xsettings by editing the code in question. Using QT_SCREEN_SCALE_FACTORS = 2 gave correct fonts but tiny icon, Audacious control boxes, and Kdenlive tracks Using QT_SCALE_FACTOR = 2 gave huge fonts, excess padding, but correctly sized icons, Audacious control boxes, and Kdenlive tracks. This can be made to mostly work (still too much padding) by specifying tiny (e.g 4px) fonts for QT

Unfortunately doing this in .bash_profile , .profile etc were ignored

[OleksandrChekhovskyi]

Another combination of options that seems to produce good results in my case is: QT_FONT_DPI=120 QT_SCALE_FACTOR=2 (with no other QT_* variables set in the environment) This was for 2.5x scale factor, for 2x use QT_FONT_DPI=96 QT_SCALE_FACTOR=2 instead. Please try this approach, maybe this is the correct way.

Regarding envrionment variables, things you set in .bash_profile are only applied inside your terminal. You could drop a script in /etc/profile.d/ to make it more global. However, just for testing various options, it's easier to open a terminal, manually unset all QT_* variables (check with env | grep QT_ to make sure nothing is there), and then launch individual applications like this: QT_FONT_DPI=120 QT_SCALE_FACTOR=2 qtcreator.

[raveit65]

Regarding envrionment variables, things you set in .bash_profile are only applied inside your terminal.

I think everything in ~/.bashrc are only applied to bash in terminal. As i said before i use export QT_AUTO_SCREEN_SCALE_FACTOR=1 in my ~/.bash_profile, and the env is applied after a session restart.

[rave@mother ~]$ printenv | grep QT_AUTO_SCREEN_SCALE_FACTOR
QT_AUTO_SCREEN_SCALE_FACTOR=1
[rave@mother ~]$ 

But it is important to disable the window-scaling-factor-qt-sync gsettings key to avoid double settings.

.......I hope i will find time today to test your proposal.

[raveit65]

@OleksandrChekhovskyi You proposal woks fine for me with all kde applications which is use include zoom which i actual use for my daily home office :) . Go ahead a add it as extra commit to PR please. Than it is better testable for all.

[raveit65]

I did another test with

From 1494c8811e4b277dd766ab7901850b26762376d4 Mon Sep 17 00:00:00 2001
From: raveit65 <mate@raveit.de>
Date: Mon, 12 Apr 2021 21:57:28 +0200
Subject: [PATCH] update_qt_scale v.2

---
 plugins/xsettings/msd-xsettings-manager.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/plugins/xsettings/msd-xsettings-manager.c b/plugins/xsettings/msd-xsettings-manager.c
index 5247523a..9e1dcd78 100644
--- a/plugins/xsettings/msd-xsettings-manager.c
+++ b/plugins/xsettings/msd-xsettings-manager.c
@@ -534,14 +534,10 @@ scale_change_workarounds (MateXSettingsManager *manager, int new_scale)
                 gsettings = g_hash_table_lookup (manager->priv->gsettings, INTERFACE_SCHEMA);
                 /* If enabled, set env variables to properly scale QT applications */
                 if (g_settings_get_boolean (gsettings, SCALING_FACTOR_QT_KEY)) {
-                        if (!update_user_env_variable ("QT_AUTO_SCREEN_SCALE_FACTOR", "0", &error)) {
+                        if (!update_user_env_variable ("QT_AUTO_SCREEN_SCALE_FACTOR", "1", &error)) {
                                 g_warning ("There was a problem when setting QT_AUTO_SCREEN_SCALE_FACTOR=0: %s", error->message);
                                 g_clear_error (&error);
                         }
-                        if (!update_user_env_variable ("QT_SCALE_FACTOR", new_scale == 2 ? "2" : "1", &error)) {
-                                g_warning ("There was a problem when setting QT_SCALE_FACTOR=%d: %s", new_scale, error->message);
-                                g_clear_error (&error);
-                        }
                 }
         } else {
                 /* Restart marco */
-- 
2.31.1

This is working for me fine too. @OleksandrChekhovskyi I am still wondering why only using this setting doesn't work for you? I am using fedora 34 beta with newest qt and kde versions and @lukefromdc use debian-testing. Maybe you#r using an olther qt or kde versions and those guys did make some improvements?

[lukefromdc]

That is essentially what I used. Fixed the QT issues, still had oversize text in the main menubar of git-gui, so that must be picking up the dpi but missing something else-and only missing it in its main menubar, which is wierd. What toolkit does that use?

Audacious, kdenlive etc all rendered correctly with this.

There is no way we can fix all the hidpi bugs of all toolkits from here, it's rather a matter of staying with the standards everyone is converging on, and getting the best real-world results that CAN be controlled from our code.

On 4/12/2021 at 4:11 PM, "raveit65" @.***> wrote:

I did another test with

From 1494c8811e4b277dd766ab7901850b26762376d4 Mon Sep 17 00:00:00 
2001
From: raveit65 ***@***.***>
Date: Mon, 12 Apr 2021 21:57:28 +0200
Subject: [PATCH] update_qt_scale v.2

---
plugins/xsettings/msd-xsettings-manager.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/plugins/xsettings/msd-xsettings-manager.c 
b/plugins/xsettings/msd-xsettings-manager.c
index 5247523a..9e1dcd78 100644
--- a/plugins/xsettings/msd-xsettings-manager.c
+++ b/plugins/xsettings/msd-xsettings-manager.c
@@ -534,14 +534,10 @@ scale_change_workarounds 
(MateXSettingsManager *manager, int new_scale)
                gsettings = g_hash_table_lookup (manager->priv-
>gsettings, INTERFACE_SCHEMA);
                /* If enabled, set env variables to properly 
scale QT applications */
                if (g_settings_get_boolean (gsettings, 
SCALING_FACTOR_QT_KEY)) {
-                        if (!update_user_env_variable 
("QT_AUTO_SCREEN_SCALE_FACTOR", "0", &error)) {
+                        if (!update_user_env_variable 
("QT_AUTO_SCREEN_SCALE_FACTOR", "1", &error)) {
                                g_warning ("There was a problem 
when setting QT_AUTO_SCREEN_SCALE_FACTOR=0: %s", error->message);
                                g_clear_error (&error);
                        }
-                        if (!update_user_env_variable 
("QT_SCALE_FACTOR", new_scale == 2 ? "2" : "1", &error)) {
-                                g_warning ("There was a problem 
when setting QT_SCALE_FACTOR=%d: %s", new_scale, error->message);
-                                g_clear_error (&error);
-                        }
                }
        } else {
                /* Restart marco */
-- 
2.31.1

This is working for me fine too. @OleksandrChekhovskyi I am still wondering why only using this setting doesn't work for you? I am using fedora 34 beta with newest qt and kde versions and @.*** use debian-testing. Maybe you#r using an olther qt or kde versions and those guys did make some improvements?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/mate-desktop/mate-settings- daemon/pull/368#issuecomment-818142183

[OleksandrChekhovskyi]

I've added the second commit with QT_FONT_DPI and QT_SCALE_FACTOR approach. Please re-check with this change specifically.

I wonder myself why QT_AUTO_SCREEN_SCALE_FACTOR=1 isn't enough on my setup. Proper answer will require debugging through Qt code, which might happen later, if I'm in the mood to dig through that mess.

Just for reference, I'm on latest Arch, which means everything is as up to date as possible. Qt5 is at 5.15.2 (and now apparently there is also Qt6, which is at 6.0.3).

[lukefromdc]

Note that I use Debian Unstable, not Debian testing. Now on to the latest test

I just tested the QT_FONT_DPI andQT_SCALE_FACTOR method (this PR as it now stands), results were identical to the QT_AUTOSCALE approach and in both cases the only problem I got was with git-gui's menubar fonts rendering huge. That probably needs to be fixed there not here

[lukefromdc]

Also I just verified that the git gui menubar font problem is not affected at all by QT settings being turned on or off. git-gui depends on the Tk toolkit, no idea where that is now supposed to stand on hidpi support

[raveit65]

Yes, git gui use Tk toolkit. I don't think that much programs use this nowadays. Last commit works fine for me, i got same results like with QT_AUTO_SCREEN_SCALE_FACTOR=1. I think we can use it, but we should check from time to time why the parameter doesn't work for you. because it is listed in archlinux wiki as usable for Qt https://wiki.archlinux.org/index.php/HiDPI#Qt_5

@vkareh What do you think about this change?

[OleksandrChekhovskyi]

Additional thoughts on the matter:

1. QT_AUTO_SCREEN_SCALE_FACTOR=1 probably gets the right UI scale factor here, but then the problem comes from crazy high font DPI, and I'm not sure where it gets that from. Speaking of that, in MATE unless I override /org/mate/desktop/font-rendering/dpi, font DPI autodetects to some ridiculous value (like over 400). Maybe Qt is getting its font DPI in the same way somehow, and that's why setting QT_FONT_DPI override helps. This requires further investigation.
2. Assuming this change goes in, users still have an option to disable this auto-magic, and configure environment as they want (e.g. in /etc/profile.d).
3. Qt does not scale correctly out of the box in GNOME either for me. It really is a Qt problem, since, for example, Chromium-derived software (Chrome, VS Code, anything electron-based) has no problem scaling correctly without further tweaking in either GNOME or MATE.

[raveit65]

I forgot to mention that i had to disable automatic detection of font DPI on my nvidia graphic system, otherwise org.mate.font-rendering dpi get crazy values and fonts are too huge. With nouveau driver auto-detection works out of box.

Maybe this makes the different?

[OleksandrChekhovskyi]

Given that there were no objections on this approach, maybe let's land this already?

[raveit65]

@lukefromdc @rbuj Any chance to test this on HIDPI? New settings works for me like a charm.

[lukefromdc]

On the road at rhe moment, but all my tests have been on a 4K monitor

[lukefromdc]

Just retested, 4K monitor as usual. Good results on conky, kdenlive, Audacious, qt5ct so now I just have to find some way of dealing with git gui's very old Tk toolkit on hidpi with Xft.dpi correctly set

[raveit65]

I just have to find some way of dealing with git gui's very old Tk toolkit on hidpi with Xft.dpi correctly set

I switched from git gui to gitg from gnome (gtk3) for that reason.

[OleksandrChekhovskyi]

I just have to find some way of dealing with git gui's very old Tk toolkit on hidpi with Xft.dpi correctly set

I switched from git gui to gitg from gnome (gtk3) for that reason.

Also tig is quite nice in the terminal.