Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xsettings: Set Xft.dpi in X resources to scaled_dpi #368

Merged
merged 2 commits into from
Apr 26, 2021

Conversation

OleksandrChekhovskyi
Copy link
Contributor

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

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
Copy link
Member

@lukefromdc lukefromdc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I do not have any known examples of the apps in question, I didn't get any ugly surprises running this either. Needs testing by someone who has an application relying on this.

@lukefromdc lukefromdc requested review from a team and lukefromdc April 9, 2021 20:57
Copy link
Member

@lukefromdc lukefromdc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This definately applies the DPI changes. On further testing this was clearly visible in Conky when set to use XFT. We DO get some issues handling fonts ourselves at 196DPI it seems, they come out rather thin, but if this is what we get with behavior consistant with GNOME, this means fonts need to be changed in HiDPI cases to fonts appropriate for such resolutions.

QT (at least with qt5ct) seems to have problems with this setting, though that's not for us to fix I suppose: I found QT apps rendering all text double-size, reducing text size in qtctl to 6 (rendered as 12) was a partial workaround.

Anyway, if this is consistant with the rest of the computing world, we need to merge it, otherwise fonts that work in GNOME etc won't look right in MATE on HiDPI.

@lukefromdc
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

raveit65 commented Apr 10, 2021

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

@OleksandrChekhovskyi
Copy link
Contributor Author

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
Copy link
Member

raveit65 commented Apr 11, 2021

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
Copy link
Member

raveit65 commented Apr 11, 2021

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

@OleksandrChekhovskyi
Copy link
Contributor Author

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-no-env-vars

QT_AUTO_SCREEN_SCALE_FACTOR=1 - everything is now huge:
qt-env-auto-screen-scale

QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCREEN_SCALE_FACTORS=2 - seems alright:
qt-env-screen-scale-factors

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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
Bildschirmfoto zu 2021-04-11 20-57-26

Any way. i will test your proposal.

@lukefromdc
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Member

@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
Copy link
Member

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
Copy link
Member

lukefromdc commented Apr 12, 2021 via email

These settings seem to produce better results in various scenarios.

Link to discussion:
mate-desktop#368
@OleksandrChekhovskyi
Copy link
Contributor Author

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
Copy link
Member

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

I just tested the QT_FONT_DPI and QT_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
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

raveit65 commented Apr 13, 2021

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.
Bildschirmfoto zu 2021-04-13 12-36-56
With nouveau driver auto-detection works out of box.

Maybe this makes the different?

@OleksandrChekhovskyi
Copy link
Contributor Author

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

@raveit65
Copy link
Member

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

@lukefromdc
Copy link
Member

lukefromdc commented Apr 20, 2021 via email

@lukefromdc
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor Author

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.

Copy link
Member

@raveit65 raveit65 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM,
this fixes several problems with HIDPI windows and runs fine.
All values are set up fine now.

@raveit65 raveit65 merged commit 24cf75b into mate-desktop:master Apr 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants