Summary: | GTK4 apps have double scaling on hidpi | ||
---|---|---|---|
Product: | [Plasma] plasmashell | Reporter: | elman |
Component: | Startup process | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ad.liu.jin, agrinev98, bednarczyk.pawel, bertyfogs+kdebugs, bruno.n.pagani, dashonwwIII, dennis.aldea, dontdieych, edoubrayrie, emilio, fedin-ilja2010, hkz85825915, kde, koloberdin, luca.bacci, nate, plasma-bugs, r9290x, rm, sausagefactory0, sn1128231220jd, steve_v, twilightinzero, uhhadd |
Priority: | HI | ||
Version: | 5.22.5 | ||
Target Milestone: | 1.0 | ||
Platform: | Other | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=465945 | ||
Latest Commit: | https://invent.kde.org/plasma/plasma-workspace/commit/e3263f0578c677507d8782bcd0494f9d60b07808 | Version Fixed In: | 5.27.1 |
Sentry Crash Report: | |||
Attachments: | blurry gtk4 app |
Description
elman
2021-09-24 15:43:03 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. >>GDK_SCALE
From what?
echo $GDK_SCALE 2 This gets set in startplasma-*.cpp. No sure if this is related, but I tried EasyEffects (GTK4) on display with scale 100 % and text seems somehow blurry. See screenshot. Created attachment 142573 [details]
blurry gtk4 app
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. 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. (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. (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? 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. (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`. 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. 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. > 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.
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. (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. 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. :) 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?). 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! Yes! I'll give it try. 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. 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! (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. (Though I believe 98340 is a typo for 98304) 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 Ok, opened: * https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2319 * https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/49 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. 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 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 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 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 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. 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). Now all Electron apps (e.g. vscode, Vivaldi) become unscaled (tiny text and controls). My setup: 240dpi screen. 250% global scale. Wayland. Electron apps in Xwayland. It was good in 5.26.90. export GDK_SCALE=1 fixes the problem. (In reply to Jin Liu from comment #34) > Now all Electron apps (e.g. vscode, Vivaldi) become unscaled (tiny text and > controls). > > My setup: 240dpi screen. 250% global scale. Wayland. Electron apps in > Xwayland. > > It was good in 5.26.90. > > export GDK_SCALE=1 fixes the problem. That's a separate issue (Bug 465733) which is already fixed in Plasma 5.27.1. Nate, it's not a right fix, the right way is to tell the right DPI via Gdk/UnscaledDPI 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. 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"? Yes, I have 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.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/56 Fixed again for 5.27.1. 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. 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. 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 (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. 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! (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. |