Bug 442901 - GTK4 apps have double scaling on hidpi
Summary: GTK4 apps have double scaling on hidpi
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Startup process (show other bugs)
Version: 5.22.5
Platform: Other Linux
: HI normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-24 15:43 UTC by elman
Modified: 2023-02-27 19:27 UTC (History)
24 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.27.1
Sentry Crash Report:


Attachments
blurry gtk4 app (72.84 KB, image/png)
2021-10-18 11:20 UTC, elman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description elman 2021-09-24 15:43:03 UTC
SUMMARY
I use Plasma on 4K display with scaling set to 200 %. PulseEffects (GTK3) worked fine, however now with EasyEffects (renamed PulseEffects and ported GTK4) installed, window is double scaled e.g. it is shown with scaling of 400 %. I tried running EasyEffects with variables GDK_SCALE and GDK_DPI_SCALE, but it doesn't seem to have any effect. Already checked with EasyEffects developers (https://github.com/wwmm/easyeffects/issues/1167) and it's not an issue with EasyEffects, because same issue exists also with gtk4-demo application.

STEPS TO REPRODUCE
1. Have 4K display with 200 % scaling
2. Install gtk4-demos
3. Run gtk4-demo

OBSERVED RESULT
Application has 400 % scaling.

EXPECTED RESULT
Application has 200 % scaling as everything else.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Manjaro Testing
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
Comment 1 Nate Graham 2021-09-24 19:15:12 UTC
Can reproduce with gtk4-demo.

If I unset GDK_SCALE, the window and most of the UI elements are the right size, but others aren't; text seems slightly too big, while icons are slightly too small (this is with Adwaita as well as breeze-gtk). I guess we need someone to see how scaling works in GTK4.
Comment 2 David Edmundson 2021-09-25 23:10:54 UTC
>>GDK_SCALE

From what?
Comment 3 Nate Graham 2021-09-25 23:55:05 UTC
echo $GDK_SCALE
2

This gets set in startplasma-*.cpp.
Comment 4 elman 2021-10-18 11:20:17 UTC
No sure if this is related, but I tried EasyEffects (GTK4) on display with scale 100 % and text seems somehow blurry. See screenshot.
Comment 5 elman 2021-10-18 11:20:50 UTC
Created attachment 142573 [details]
blurry gtk4 app
Comment 6 elman 2021-12-27 08:48:47 UTC
Hi. Any progress on the issue? There are more and more applications being ported to GTK4 (Text Pieces, Kooha, Authenticator, ...), so this issue is becoming more annoying.
Comment 7 EP 2022-01-23 05:37:59 UTC
It looks like the GDK_DPI_SCALE variable used to offset the font size isn't being used anymore by GTK4 https://github.com/GNOME/gtk/blob/0579220546f7daff16a907f4c3256098c344e40c/NEWS.pre-4.0#L1308. My workaround is to halve the font size in the settings.ini.
Comment 8 elman 2022-01-27 08:40:11 UTC
(In reply to Eugene from comment #7)
> My workaround is to halve the font size in the settings.ini.

Works all right also for me. Thanks for the tip.
Comment 9 Dennis Aldea 2022-05-25 20:35:43 UTC
(In reply to Felis from comment #7)
> It looks like the GDK_DPI_SCALE variable used to offset the font size isn't
> being used anymore by GTK4
> https://github.com/GNOME/gtk/blob/0579220546f7daff16a907f4c3256098c344e40c/
> NEWS.pre-4.0#L1308. My workaround is to halve the font size in the
> settings.ini.

Changes made to `~/.config/gtk-4.0/settings.ini` do not take effect; the file is rewritten at startup.
I have been explictly setting `GDK_SCALE=1` whenever I run a GTK4 application. Is there any way to persistently change this setting for GTK4 apps only?
Comment 10 Nate Graham 2022-05-25 20:44:22 UTC
If that environment variable does something different for GTK4 apps compared to GTK3 apps, that's pretty unfortunate. I don't know if it's possible for us to conditionalize it in Plasma code based on the GTK toolkit version.
Comment 11 EP 2022-05-26 10:56:24 UTC
(In reply to Dennis Aldea from comment #9)
> Changes made to `~/.config/gtk-4.0/settings.ini` do not take effect; the
> file is rewritten at startup.
> I have been explictly setting `GDK_SCALE=1` whenever I run a GTK4
> application. Is there any way to persistently change this setting for GTK4
> apps only?
If you don't change the settings that often you can lock the file with `chattr +i`.
Comment 12 FiveYellowMice 2022-06-04 05:42:46 UTC
It's peculiar why GTK4 doesn't use GDK_DPI_SCALE anymore while not providing an apparent alternative. Do they want to impose `Xft.dpi: 96` on any displays, and rely on GDK_SCALE alone to scale the app? If that's what they want, it can be done with Plasma:

1. Go to System Settings >> Appearance >> Fonts, disable "Force font DPI", this unsets Xft.dpi. This setting is enabled automatically whenever "Global scale" is changed in System Settings >> Display and Monitor >> Display Configuration.
2. Create `~/.config/plasma-workspace/env/90-unset-gdk-dpi-scale.sh` with the content `export GDK_DPI_SCALE=-1`, this overrides the environment variable `GDK_DPI_SCAL=0.5` set by startplasma-x11.cpp when global scale is 2.

Doing these will make applications see GDK_SCALE=2, GDK_DPI_SCALE=-1 and an Xft.dpi of nothing, making both GTK3 and 4 happily produce 2x scaled windows. But it would also surely break other apps who uses Xft.dpi to scale their UIs, e.g. Wine, GLFW, making them unscaled. It also feels incredibly wrong to override 2 default behaviours of Plasma.

It feels like that setting GDK_SCALE=2, GDK_DPI_SCALE=0.5 and `Xft.dpi: 192` used to be the best way of configuring a 2x scaled display, but GTK4 just comes and decides to break that. Now we have a dillema of either having large GTK4 apps, or small Xft.dpi-scaled apps.
Comment 13 Nate Graham 2022-06-06 17:42:46 UTC
Yes, it's quite possible this this is an oversight on the part of the GTK developers and that they'll need to fix it or offer us anothe renvironment variable we can use. Feel free to investigate further and file a bug report for them at https://gitlab.gnome.org/GNOME/gtk/-/issues/, and then paste the URL of the bug report in the URL field above.
Comment 14 sausagefactory0 2022-06-12 13:06:53 UTC
> Yes, it's quite possible this this is an oversight on the part of the GTK developers 
> and that they'll need to fix it or offer us anothe renvironment variable we can use. 
> Feel free to investigate further and file a bug report for them at https://gitlab.gnome.org/GNOME/gtk/-/issues/,
> and then paste the URL of the bug report in the URL field above.

How does GNOME handle this? GTK4 apps work fine on GNOME, right? I doubt this can be considered their problem if so.
Comment 15 Nate Graham 2022-06-13 17:20:06 UTC
I've since heard that they use xsettings for that, and our usage of environment variables is brittle. We should maybe consider using xsettings too.
Comment 16 sn1128231220jd 2022-08-23 16:23:05 UTC
(In reply to sausagefactory0 from comment #14)
> > Yes, it's quite possible this this is an oversight on the part of the GTK developers 
> > and that they'll need to fix it or offer us anothe renvironment variable we can use. 
> > Feel free to investigate further and file a bug report for them at https://gitlab.gnome.org/GNOME/gtk/-/issues/,
> > and then paste the URL of the bug report in the URL field above.
> 
> How does GNOME handle this? GTK4 apps work fine on GNOME, right? I doubt
> this can be considered their problem if so.

They read the dconf key /org/gnome/desktop/interface/text-scaling-factor, which can be set using GNOME Tweaks, gsettings, or dconf directly.
Comment 17 Nate Graham 2022-08-24 21:58:34 UTC
We didn't end up making any changes yet, but I can no longer reproduce this issue with gtk4-demo, and I was able to before. Blanket which uses GTK4 is also scaled correctly for me with 200% scaling. So it looks like the GTK devs eventually made GTK4 respect the environment variable that we're already setting, which means there's nothing for us to do here. :)
Comment 18 FiveYellowMice 2022-08-31 19:31:47 UTC
I don't think the issue has been fixed on GTK's side, I still have 400% scaled text while using the latest version of GTK (4.6.7), and there doesn't seem to be any code mentioning `GDK_DPI_SCALE` in GTK's repo. Perhaps your Xft.dpi has been changed to 96 for some reason? That would make text on GTK 4 apps appear correct, but GTK 3 apps would then have tiny text because of the `GDK_DPI_SCALE=0.5` set by `startplasma-*.cpp`.

I went through some digging in the GTK codebase and fiddling in a VM running GNOME 4 X11 set to 200% scale, here are my findings:

1. This is where GTK 3 used to read `GDK_DPI_SCALE`, and it hasn't come back since GTK 4.
https://github.com/GNOME/gtk/blob/e670720d196bac1cef6f88313f6514cdd8c4a0c5/gdk/x11/xsettings-client.c#L495

2. This is where `GDK_SCALE` is read in both GTK 3 and 4. Note that the flag `x11_screen->fixed_window_scale` will then be set to true.
https://github.com/GNOME/gtk/blob/d3ffc0c3bb72cddf57b564c0ac31c70f7bc8e504/gdk/x11/gdkscreen-x11.c#L892

3. GNOME doesn't set either of the environment variables `GDK_SCALE` or `GDK_DPI_SCALE`, but instead provides the scaling information with GNOME Settings Daemon, through an XSettings value `Gdk/WindowScalingFactor`, which is set to 2. This code seems to be responsible for reading it, which is only run when `x11_screen->fixed_window_size` is false, meaning the XSettings value is ignored when `GDK_SCALE` is set, so far so good.
https://github.com/GNOME/gtk/blob/e670720d196bac1cef6f88313f6514cdd8c4a0c5/gdk/x11/xsettings-client.c#L506

4. GNOME also seems to set the Xrdb value Xft.dpi to 192, but doesn't have giant text. The reason is probably the code here. GTK reads another XSettings value `Gdk/UnscaledDPI` which is 98340, and overrides `Xft/DPI` which was 196608 on the client side.
https://github.com/GNOME/gtk/blob/e670720d196bac1cef6f88313f6514cdd8c4a0c5/gdk/x11/xsettings-client.c#L452

This is like having a GTK-specific override for the Xrdb value `Xft.dpi` to be 96. This works with both GTK 3 and 4. I think this is exactly what we want: We want to have all other apps see Xft.dpi being 192, but GTK 3 and 4 to see 96, so that we wouldn't need the defunct `GDK_DPI_SCALE` environment variable, it's what GNOME does. The only caveat being, `Gdk/UnscaledDPI` is only used when `x11_screen->fixed_window_scale` is false, i.e. when `GDK_SCALE` is not set. But Plasma sets it.

xsettingsd is already used by KDE GTK Configurator, so I manually added `Gdk/WindowScalingFactor 2` and `Gdk/UnscaledDPI 98340` to `~/.config/xsettingsd/xsettingsd.conf`, sent SIGHUP to xsettingsd, then restart a GTK 3 or 4 app while having `GDK_SCALE` and `GDK_DPI_SCALE` unset. I then finally have correctly scaled text and UI for all of GTK 3, 4, Qt, GLFW!

There doesn't seem to be a way to unset a environment variable set by Plasma through a script in `~/.config/plasma-workspace/env` though, so I can't find an elegant workaround. Perhaps this should be made the default for Plasma, ditch `GDK_SCALE` and `GDK_DPI_SCALE` from `startplasma-*.cpp`, and instead let KDE GTK Configurator tell xsettingsd to provide the 2 aforementioned XSettings values.

I've only explored things on X11, so I don't know about Wayland (probably more complex with their different scales for each screen?).
Comment 19 Nate Graham 2022-09-01 14:44:30 UTC
Thanks for the detailed findings. Would you be willing to work on this issue? It seems like you have the technical skills and the motivation!
Comment 20 FiveYellowMice 2022-09-02 14:45:27 UTC
Yes! I'll give it try.
Comment 21 dontdieych 2022-10-13 09:06:56 UTC
https://dontdieych.github.io/comment_bugs_kde.html - full output

> xsettingsd is already used by KDE GTK Configurator, so I manually added
> Gdk/WindowScalingFactor 2 and Gdk/UnscaledDPI 98340 to
> ~/.config/xsettingsd/xsettingsd.conf, sent SIGHUP to xsettingsd, then restart
> a GTK 3 or 4 app while having GDK_SCALE and GDK_DPI_SCALE unset. I then
> finally have correctly scaled text and UI for all of GTK 3, 4, Qt, GLFW!

Thanks. It's working for me too. bottles and easyeffects

One problem is, easyeffects is double scaled again after first launch. After reboot it looks correctly once then fall back to double scale.

bottles is fine.
Comment 22 Nate Graham 2022-11-02 18:04:06 UTC
As of the fix for Bug 443215, we no longer set GDK_SCALE and GDK_DPI_SCALE anymore in Plasma's startup code. That fix will be shipped in Plasma 5.26.3.

Can people see if that change is sufficient to fix this out of the box, or if more changes are needed? Thanks!
Comment 23 Bruno Pagani 2022-11-05 21:23:34 UTC
(In reply to Nate Graham from comment #22)
> As of the fix for Bug 443215, we no longer set GDK_SCALE and GDK_DPI_SCALE
> anymore in Plasma's startup code. That fix will be shipped in Plasma 5.26.3.
> 
> Can people see if that change is sufficient to fix this out of the box, or
> if more changes are needed? Thanks!

There is definitively more required. Unsetting those means that now the fonts are correctly scaled, but everything else in the UI is not (both for GTK3 and GTK4 app). https://bugs.kde.org/show_bug.cgi?id=442901#c18 provided extended information on the topic.
Comment 24 Bruno Pagani 2022-11-05 21:27:29 UTC
(Though I believe 98340 is a typo for 98304)
Comment 25 Luca Bacci 2022-11-10 15:05:28 UTC
Hello! KDE/Plasma implements scaling of GTK applications by setting an intelligent mix of global scale and text scale. That's also what GTK currently does on Windows, FWIW. However the environment variables GDK_SCALE and GDK_DPI_SCALE are just meant for quick testing of applications. Two GTK settings should be used, instead:

* For the global scale:
   * Gdk/WindowScalingFactor, gdk-window-scaling-factor
* For the text scale, either:
   * Xft/DPI, gtk-xft-dpi
   * Gdk/UnscaledDPI, gdk-unscaled-dpi (has precedence over the xft)

I'll prepare an MR to make use of those settings. Note that GTK4 dropped usage of GDK_DPI_SCALE but still reads all the reported settings (and will continue doing so!)

PS: Actually I'm going to open two MRs: one in plasma-workspace to drop usage of the env vars and one in kde-gtk-config to make use of the settings
Comment 27 Bruno Pagani 2023-01-19 15:09:19 UTC
I see that 5.27 beta is out, but the two MRs are still open… Is there any hope for this to be fixed in 5.27 ? Since it’s supposed to be the last version for a while before 6.0 is released, it would be good not to miss it.
Comment 28 Fushan Wen 2023-01-26 12:41:02 UTC
Git commit 1debd2e0833fd62e2e1c1837387fcc1c3436340a by Fushan Wen, on behalf of Luca Bacci.
Committed on 26/01/2023 at 12:40.
Pushed by fusionfuture into branch 'master'.

Set DPI scaling settings for GTK on Plasma/X11 sessions

GTK4 dropped support for the GDK_DPI_SCALE environment variable, but we can achieve the same using dedicated GTK/GDK settings. Here we drop any usage of environment variables for DPI configuration in favor of GTK/GDK settings.
FIXED-IN: 5.27

M  +1    -0    .kde-ci.yml
M  +1    -1    CMakeLists.txt
M  +1    -0    kded/CMakeLists.txt
M  +25   -0    kded/configvalueprovider.cpp
M  +4    -0    kded/configvalueprovider.h
M  +43   -0    kded/gtkconfig.cpp
M  +2    -0    kded/gtkconfig.h

https://invent.kde.org/plasma/kde-gtk-config/commit/1debd2e0833fd62e2e1c1837387fcc1c3436340a
Comment 29 Fushan Wen 2023-01-26 12:42:01 UTC
Git commit 87cb9018088eb31789aed0678f234e9a6bd2662a by Fushan Wen, on behalf of Luca Bacci.
Committed on 26/01/2023 at 12:41.
Pushed by fusionfuture into branch 'cherry-pick-1debd2e0'.

Set DPI scaling settings for GTK on Plasma/X11 sessions

GTK4 dropped support for the GDK_DPI_SCALE environment variable, but we can achieve the same using dedicated GTK/GDK settings. Here we drop any usage of environment variables for DPI configuration in favor of GTK/GDK settings.
FIXED-IN: 5.27


(cherry picked from commit 1debd2e0833fd62e2e1c1837387fcc1c3436340a)

M  +1    -0    .kde-ci.yml
M  +1    -1    CMakeLists.txt
M  +1    -0    kded/CMakeLists.txt
M  +25   -0    kded/configvalueprovider.cpp
M  +4    -0    kded/configvalueprovider.h
M  +43   -0    kded/gtkconfig.cpp
M  +2    -0    kded/gtkconfig.h

https://invent.kde.org/plasma/kde-gtk-config/commit/87cb9018088eb31789aed0678f234e9a6bd2662a
Comment 30 Fushan Wen 2023-01-26 14:50:26 UTC
Git commit e3263f0578c677507d8782bcd0494f9d60b07808 by Fushan Wen, on behalf of Luca Bacci.
Committed on 26/01/2023 at 14:50.
Pushed by fusionfuture into branch 'cherry-pick-ba1f944e'.

X11: Do not set the GDK_SCALE / GDK_DPI_SCALE environment variables

The primary method for setting the global and text scale for GTK
applications is by using the `gdk-window-scaling-factor` and
`gdk-unscaled-dpi` settings. Those are also read by GTK4, which
at the same time dropped usage of GDK_DPI_SCALE.

Note that the scaling settings are only relevant on X11; On Wayland
the DPI scale is communicated directly by KWin to applications on
a per-monitor basis.

See also https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/49


(cherry picked from commit ba1f944e124286f4aa4217a108fff2a641eee240)

M  +0    -5    startkde/startplasma-x11.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/e3263f0578c677507d8782bcd0494f9d60b07808
Comment 31 Fushan Wen 2023-01-26 15:19:10 UTC
Git commit 7197eb34bf12d1e07ec1a3015924ba8ec32e2f1e by Fushan Wen, on behalf of Luca Bacci.
Committed on 26/01/2023 at 15:19.
Pushed by fusionfuture into branch 'master'.

X11: Do not set the GDK_SCALE / GDK_DPI_SCALE environment variables

The primary method for setting the global and text scale for GTK applications is by using the `gdk-window-scaling-factor` and `gdk-unscaled-dpi` settings. Those are also read by GTK4, which at the same time dropped usage of GDK_DPI_SCALE.

Note that the scaling settings are only relevant on X11; On Wayland the DPI scale is communicated directly by KWin to applications on a per-monitor basis.

See also https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/49
FIXED-IN: 5.27

M  +0    -5    startkde/startplasma-x11.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/7197eb34bf12d1e07ec1a3015924ba8ec32e2f1e
Comment 32 Steve Vialle 2023-02-17 00:39:41 UTC
As of plasma 5.27.0, this change breaks GTK font scaling on systems where display DPI <96. This is most notable in firefox.

Inspecting generated ~.config/xsettingsd/xsettingsd.conf shows:
Gdk/UnscaledDPI 98304

Where 98304/1024 = 96
That's 96DPI folks, I don't know where plasma is getting it but it's flat-out wrong on this system.

This is an  _82DPI_ display, as reported by:
X11 / GPU driver / Monitor EDID: AMDGPU(0): DPI set to (82, 82)
xdpyinfo: resolution:    82x82 dots per inch
xrdb: Xft.dpi:        82
A frickin' ruler and a calculator.
On top of that, "force fonts DPI" is set to 82 in the fonts KCM.

Setting 'Gdk/UnscaledDPI 83968' in xsettingsd.conf (1024x82) and marking that file immutable so plasma can't screw with it restores correct font scaling in GTK3 applications.

If plasma is going to pass this setting to xsettingsd, it should _at least_ respect the setting of "force fonts DPI" in the fonts KCM. Ideally that setting should be entirely unnecessary anyway, as there is a perfectly good autodetected value available from X11.
Comment 33 Ilya Fedin 2023-02-17 02:29:10 UTC
I, on other hand, have a problem that Gdk/UnscaledDPI doesn't represent fractional scaling for Xwayland. It seems it always returns 96 now while it should extract the fractional part from scaling factor as gtk doesn't support fractional scaling (and Electron uses that for its fractional scaling).
Comment 34 Jin Liu 2023-02-17 05:27:19 UTC Comment hidden (spam)
Comment 35 Nate Graham 2023-02-17 05:31:16 UTC Comment hidden (spam)
Comment 36 Ilya Fedin 2023-02-17 05:34:02 UTC
Nate, it's not a right fix, the right way is to tell the right DPI via Gdk/UnscaledDPI
Comment 37 Nate Graham 2023-02-17 18:22:46 UTC
I have no doubt that there's a better fix for Bug 465733, but for now we wanted to simply revert the bad commit to unbreak things as quickly as possible. Alternatives are being investigated. I'll look into them soon.
Comment 38 Luca Bacci 2023-02-17 18:30:27 UTC
Hi! Sorry for the regressions! I'm opening a Merge Request with the necessary fixes.

@Steve Vialle: thanks for the report! Actually I didn't know that DPI less than 96 were supported, sorry! :) I'm going to remove that limitation (it's just one-liner fix)

@Ilya Fedin, @Jin Liu: Thanks! If you open System Settings > Display and Monitor > Display Configuration, do you have Legacy Applications (X11) set to "Apply scaling by themselves"?
Comment 39 Ilya Fedin 2023-02-17 18:42:09 UTC
Yes, I have
Comment 40 Trent M 2023-02-18 00:07:37 UTC
Hi there. I hopped back to Neon from Kubuntu 22.04 to get Plasma 5.27, and discovered that the fix discussed here breaks my setup as well. I have manually defined fonts DPI of 120. The DPI was changed not just in xsettingsd, but also in gtk-{3,4}.0/settings.ini as well. I worked around it by changing those values to 122880 (120 * 1024) and making the files immutable.

> If plasma is going to pass this setting to xsettingsd, it should _at least_ respect the setting of "force fonts DPI" in the fonts KCM.

100% this. Hardcoding a value for a workaround when it's based on something configurable is never correct.
Comment 41 Bug Janitor Service 2023-02-18 14:37:41 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/56
Comment 42 Nate Graham 2023-02-21 16:35:20 UTC
Fixed again for 5.27.1.
Comment 43 Steve Vialle 2023-02-22 04:26:41 UTC
Not only is this still not fixed WRT DPI <96, the situation is now _worse_ than it was with 5.27.0.
GTK3 and QT/KDE fonts are now the same DPI, so that's something... But that DPI is 96, and _everything_ is huge. 
It appears "force fonts DPI" is now being ignored altogether, and plasma is setting Xft.dpi to 96 unconditionally.

xsettingsd.conf as of 5.27.1:
Xft/DPI 98304
Gdk/UnscaledDPI 98304

Again, this is an _82_ DPI display, and that information is both readily available and manually provided in the fonts KCM.

5.27.0:
~ $ xdpyinfo | grep -B2 resolution
screen #0:
  dimensions:    1920x1080 pixels (594x334 millimeters)
  resolution:    82x82 dots per inch
~ $ xrdb -query | grep dpi
Xft.dpi:        82

5.27.1:
~ $ xdpyinfo | grep -B2 resolution
screen #0:
  dimensions:    1920x1080 pixels (594x334 millimeters)
  resolution:    82x82 dots per inch
~ $ xrdb -query | grep dpi
Xft.dpi:        96

No software or config changes on my end besides updating plasma.
Comment 44 Steve Vialle 2023-02-22 04:34:09 UTC
Additional quick tests:
Setting Xft.dpi to 82 in /etc/X11/Xresources -> plasma/QT/GTK all 96DPI.
Setting "DPI" "82x82" in /etc/X11/xorg.conf.d/foo.conf -> plasma runs at 96DPI.
Setting "Force fonts DPI to 82 in fonts KCM -> plasma runs at 96DPI.

_Please_ stop overriding my settings.
Comment 45 Luca Bacci 2023-02-22 09:26:43 UTC
Hi @SteveVialle! We fixed the issue of unscaled XWayland apps for KDE 5.27.1, but unfortunately I had to cut out the part which properly reads Xft.DPI due to the imminence of the 5.27.1 release. I'm sorry about that, but the code wasn't tested (I added that the day before the release) and as such could have caused too many regressions. I'm working on a proper MR right now :)

See https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/56#note_625653, https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/56#note_625789

Best,
Luca
Comment 46 Steve Vialle 2023-02-22 12:02:13 UTC
(In reply to Luca Bacci from comment #45)
> We fixed the issue of unscaled XWayland apps for KDE
> 5.27.1, but unfortunately I had to cut out the part which properly reads
> Xft.DPI due to the imminence of the 5.27.1 release.

So, IOW, "We hurriedly worked around the latest GTK crazy, at the expense of breaking both manual DPI settings in X11 and our own fonts control module."? :raisedeyebrow:
GTK4+HiDPI really that special, huh?

WIP, got it, cool, and thanks. Guess I'll just keep my xsettingsd.conf immutable and out of plasmas meddling paws while I look forward to the _real_ fix.


If we need a new bug report to track this (as it's not really about GTK4 any more), cool. I'm not convinced this one deserves a "fixed" tag when the "fix" introduces additional regressions though.
Comment 47 Nate Graham 2023-02-22 14:02:08 UTC
Yes, we need a new bug report ad the issue this bug report is about has been fixed. Can you submit a new one describing the regression in detail? Thanks!
Comment 48 Hasshu 2023-02-27 19:27:39 UTC
(In reply to Steve Vialle from comment #46)
> If we need a new bug report to track this (as it's not really about GTK4 any
> more), cool. I'm not convinced this one deserves a "fixed" tag when the
> "fix" introduces additional regressions though.

That seems to be Bug 466463.