In Plasma 5.26 Wayland, Slack would handle mixed DPI scenarios correctly launch with the correct scale for the monitor it was launched from. In 5.27, Slack defaults to *shrinking* to compensate for what plasma tells it the dpi should be, meaning it renders at 100% on the screen it was launched from, and if the screen it was launched from is higher dpi than another screen, then Slack is *smaller than 100%* on that screen. I'm not sure if this makes sense, but essentially, what was working fine in 5.26 is now broken in 5.27. I don't know if this is an issue with all electron apps, because Spotify still works the same as it did before.
How Slack works around HiDPI is unknown to us. Somebody should ask for support from Slack.
Slack is an electron app. I was able to get slack working properly again by launching it with the ozone flags, but that requires editing the .desktop file. I am wondering if anything changed in 5.27 vs 5.26, since in 5.26 I didn't have to do anything and I was running slack as xwayland and not wayland. My slack version has not changed, since I installed it from a .deb file so it doesn't have any way to update itself. On 2/15/23 11:21, Fushan Wen wrote: > https://bugs.kde.org/show_bug.cgi?id=465733 > > Fushan Wen <qydwhotmail@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |qydwhotmail@gmail.com > > --- Comment #1 from Fushan Wen <qydwhotmail@gmail.com> --- > How Slack works around HiDPI is unknown to us. Somebody should ask for support > from Slack. >
If other electron apps don't have the same bug, it's definitely slack doing some workarounds that are not applicable to Plasma 5.27 anymore.
Hm, that would make sense On 2/15/23 11:27, Fushan Wen wrote: > https://bugs.kde.org/show_bug.cgi?id=465733 > > --- Comment #3 from Fushan Wen <qydwhotmail@gmail.com> --- > If other electron apps don't have the same bug, it's definitely slack doing > some workarounds that are not applicable to Plasma 5.27 anymore. >
Nothing has changed in kwin with regards to this. Some changes have been made in start kde to configure preferred font sizes and DPI - this is much more likely the cause. >I'm not sure if this makes sense, Not entirely. You have one 1x screen, one 2x screen. And it's consistently half the size it should be? > on the screen it was launched from Can you confirm that makes a difference? I would be surprised.
*** Bug 465853 has been marked as a duplicate of this bug. ***
Comment in another thread says: ``` If I run it with GDK_SCALE set, it starts normally as I usually see it. It doesn't matter if I set "GDK_SCALE" or "GDK_SCALE=1", result is the same. I didn't use any env variables before so I think there could be some regression. ```
All signs point to 63de3d6f1716a6924fa5924b5a57af4abaa4460f Though this was cherry-picked to 5.26.3
I haven't had time to test this more, but > Not entirely. You have one 1x screen, one 2x screen. And it's consistently half the size it should be? I have one 1x screen, one 1.5x screen. The slack app launches scaled down on the 1.5x screen s.t. the effective scale for slack is 1x (so 0.66x scaling). On the 1x screen, it is then 0.66x. This happens if I launch it on the 1x screen too. If I only have the 1x screen connected and launch slack, then it is fine and launches at 1x. On 2/16/23 12:22, David Edmundson wrote: > https://bugs.kde.org/show_bug.cgi?id=465733 > > David Edmundson <kde@davidedmundson.co.uk> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Component|wayland-generic |Startup process > Product|kwin |plasmashell > Target Milestone|--- |1.0 > Assignee|kwin-bugs-null@kde.org |plasma-bugs@kde.org > > --- Comment #8 from David Edmundson <kde@davidedmundson.co.uk> --- > All signs point to 63de3d6f1716a6924fa5924b5a57af4abaa4460f > > Though this was cherry-picked to 5.26.3 >
I can confirm that my visual studio code starts at 1x (normally it should be 1.5), but in plasma 5.26 it starts at 1.5x
Investigated this today. 63de3d6f1716a6924fa5924b5a57af4abaa4460f does indeed seem suspicious. Unfortunately I can't try Slack because it doesn't seem to show its main UI after launch, just the tray icon. Console log says, "Error sending from webFrameMain: Error: Render frame was disposed before WebFrameMain could be accessed" I did manage to I did try with Discord (an Electron app running in XWayland mode), 2 screens (one at 200% and one at 100%), and the "Legacy Applications (X11): Apply scaling themselves" setting. I launched it using GUI methods. No matter which screen Discord was launched on, it got the right scale factor for me. I also tested with VSCode, and got a different result: When launched on the 200% scale screen, it was drawn at 100% scale. When launched on the 100% scale screen, it was all blurry, like it was actually being drawn at 50% and upscaled. When I set the GDK_SCALE=1 environment variable and re-launched VS Code in the terminal window that I set the envar in, it was drawn correctly. Interestingly, when I tried the same trick with Discord, running it from that same terminal window, it was only drawn correctly while GDK_SCALE=1 was set. When I unset it, or ran `flatpak run com.discordapp.Discord` from a terminal window where I hadn't set it, I got the same initial result as VS Code: being drawn too small. So it seems like these apps do in fact need GTK_SCALE=1 to be set or else they don't get launched with the right scale factor. The mystery is why that envar manages to gets set for Discord when launched from a GUI method like Kickoff or KRunner, but it doesn't happen for VS Code.
(In reply to Nate Graham from comment #11) > Investigated this today. 63de3d6f1716a6924fa5924b5a57af4abaa4460f does > indeed seem suspicious. > > Unfortunately I can't try Slack because it doesn't seem to show its main UI > after launch, just the tray icon. Console log says, "Error sending from > webFrameMain: Error: Render frame was disposed before WebFrameMain could be > accessed" > > I did manage to I did try with Discord (an Electron app running in XWayland > mode), 2 screens (one at 200% and one at 100%), and the "Legacy Applications > (X11): Apply scaling themselves" setting. I launched it using GUI methods. > No matter which screen Discord was launched on, it got the right scale > factor for me. > > I also tested with VSCode, and got a different result: When launched on the > 200% scale screen, it was drawn at 100% scale. When launched on the 100% > scale screen, it was all blurry, like it was actually being drawn at 50% and > upscaled. > > When I set the GDK_SCALE=1 environment variable and re-launched VS Code in > the terminal window that I set the envar in, it was drawn correctly. > Interestingly, when I tried the same trick with Discord, running it from > that same terminal window, it was only drawn correctly while GDK_SCALE=1 was > set. When I unset it, or ran `flatpak run com.discordapp.Discord` from a > terminal window where I hadn't set it, I got the same initial result as VS > Code: being drawn too small. > > So it seems like these apps do in fact need GTK_SCALE=1 to be set or else > they don't get launched with the right scale factor. The mystery is why that > envar manages to gets set for Discord when launched from a GUI method like > Kickoff or KRunner, but it doesn't happen for VS Code. I was able to confirm that after I set GDK_SCALE=1 the scaling of visual studio code and discord finally worked fine
Found the reason why Discord works for me when launched using GUI methods: I had a local override of Discord's .desktop file in ~/.local/share/applications that had "--force-device-scale-factor=2" appended to its CLI args. This works around the problem and was probably a leftover from before we had XWayland client scaling, and I set it to make Discord look better and then forgot about it. So when I wrote https://invent.kde.org/plasma/plasma-workspace/-/commit/63de3d6f1716a6924fa5924b5a57af4abaa4460f, I didn't notice that it had regressed XWayland-using Electron apps because the only such app I interact with had been locally configured to work around the bug. Oops. This is probably a bug in Electron, as other XWayland-using apps don't seem to require GDK_SCALE=1 to be set in the environment to be scaled properly under XWayland. But it's probably not reasonable to expect it to be fixed anytime soon given the glacial pace of development and general lack of attention paid to Linux as a platform. Nevertheless I'll report the bug upstream and restore the workaround in our code, with a comment explaining why it's needed.
(In reply to Nate Graham from comment #13) In fact, scaling with "--force-device-scale-factor=2" has a side effect that the application's file picker dialog is not scaled either, which makes the software look inconsistent
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2635
Git commit 34e3efd85252182977178ab99435b99a1ba987b9 by Nate Graham. Committed on 16/02/2023 at 21:43. Pushed by ngraham into branch 'master'. Revert "startplasma-wayland: Don't set GDK_SCALE and GDK_DPI_SCALE" This reverts commit 63de3d6f1716a6924fa5924b5a57af4abaa4460f. This change was incorrect and the original logic for it was backwards; it was stated that keeping it causes non-GTK XWayland (e.g. Electron) apps to be scaled incorrectly. But in fact the opposite was true; getting rid of it was what causes them to be scaled incorrectly! This mistake was made due to due to the presence of a loca workaround on my system that inverted the behavior. Related: bug 443215 FIXED-IN: 5.27.1 M +6 -0 startkde/startplasma-wayland.cpp https://invent.kde.org/plasma/plasma-workspace/commit/34e3efd85252182977178ab99435b99a1ba987b9
Git commit ba49bb121d7d6752b61aec29ae01a13e7978bd26 by Nate Graham. Committed on 16/02/2023 at 21:47. Pushed by ngraham into branch 'Plasma/5.27'. Revert "startplasma-wayland: Don't set GDK_SCALE and GDK_DPI_SCALE" This reverts commit 63de3d6f1716a6924fa5924b5a57af4abaa4460f. This change was incorrect and the original logic for it was backwards; it was stated that keeping it causes non-GTK XWayland (e.g. Electron) apps to be scaled incorrectly. But in fact the opposite was true; getting rid of it was what causes them to be scaled incorrectly! This mistake was made due to due to the presence of a loca workaround on my system that inverted the behavior. Related: bug 443215 FIXED-IN: 5.27.1 (cherry picked from commit 34e3efd85252182977178ab99435b99a1ba987b9) M +6 -0 startkde/startplasma-wayland.cpp https://invent.kde.org/plasma/plasma-workspace/commit/ba49bb121d7d6752b61aec29ae01a13e7978bd26
I really wonder why Plasma prefers setting debug variables like QT_SCREEN_SCALE_FACTORS, GDK_SCALE and GDK_DPI_SCALE and then getting various weird bugs rather than telling the DPI and scale factor properly via Xresources and XSETTINGS
*** Bug 465945 has been marked as a duplicate of this bug. ***
Generally because we lack the knowledge to know what the best approach is, due to unfamiliarity with the GTK world. The reason why I removed those random envars from our startup process was to try to move gradually towards doing things in the better way. Apparently it blew up because we didn't also fix Bug 464132 properly at the same time. Or maybe it was something else. If you have knowledge about how to fix this mess in a better way without regressing any apps in the process, please do share it.
Copy the plasma-workspace's logic of setting Xft.dpi to kde-gtk-config's Gdk/UnscaledDPI with the difference that the Xwayland case should represent only fractional factor (e.g. 2.25 becomes Gdk/WindowSclaingFactor = 2, Gdk/UnscaledDPI = 1.25 * 96 * 1024)
https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kcms/fonts/fontinit.cpp#L20-34
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2643
Git commit 95a66e22d484d9291f79770643865477e5f4aef8 by Fushan Wen. Committed on 18/02/2023 at 09:31. Pushed by fusionfuture into branch 'master'. Unset `Gdk/UnscaledDPI` and `Gdk/WindowScalingFactor` on Wayland XWayland GTK applications also need to be considered. FIXED-IN: 5.27.1 M +12 -2 kded/config_editor/xsettings.cpp M +1 -0 kded/config_editor/xsettings.h M +10 -8 kded/gtkconfig.cpp https://invent.kde.org/plasma/kde-gtk-config/commit/95a66e22d484d9291f79770643865477e5f4aef8
Git commit cdf2e1a9abf7cdee24828f59aa7cc2295dee4877 by Fushan Wen. Committed on 18/02/2023 at 09:28. Pushed by fusionfuture into branch 'master'. Revert "Revert "startplasma-wayland: Don't set GDK_SCALE and GDK_DPI_SCALE"" This reverts commit 34e3efd85252182977178ab99435b99a1ba987b9 and bd9c257dcdf050f74a691c31663cbca68ce8d8e7 Related: bug 443215 M +0 -12 startkde/startplasma-wayland.cpp https://invent.kde.org/plasma/plasma-workspace/commit/cdf2e1a9abf7cdee24828f59aa7cc2295dee4877
Git commit 14c5b464f41f2b858453fd102ed57397755f9c26 by Fushan Wen. Committed on 18/02/2023 at 09:50. Pushed by fusionfuture into branch 'cherry-pick-cdf2e1a9'. Revert "Revert "startplasma-wayland: Don't set GDK_SCALE and GDK_DPI_SCALE"" This reverts commit 34e3efd85252182977178ab99435b99a1ba987b9 and bd9c257dcdf050f74a691c31663cbca68ce8d8e7 Related: bug 443215 (cherry picked from commit cdf2e1a9abf7cdee24828f59aa7cc2295dee4877) M +0 -12 startkde/startplasma-wayland.cpp https://invent.kde.org/plasma/plasma-workspace/commit/14c5b464f41f2b858453fd102ed57397755f9c26
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2644
Git commit 761cf85843a250da09390d23325f0bd33dadad6b by Fushan Wen. Committed on 18/02/2023 at 09:51. Pushed by fusionfuture into branch 'cherry-pick-95a66e22'. Unset `Gdk/UnscaledDPI` and `Gdk/WindowScalingFactor` on Wayland XWayland GTK applications also need to be considered. FIXED-IN: 5.27.1 (cherry picked from commit 95a66e22d484d9291f79770643865477e5f4aef8) M +12 -2 kded/config_editor/xsettings.cpp M +1 -0 kded/config_editor/xsettings.h M +10 -8 kded/gtkconfig.cpp https://invent.kde.org/plasma/kde-gtk-config/commit/761cf85843a250da09390d23325f0bd33dadad6b
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/56
>I really wonder why Plasma prefers setting debug variables like QT_SCREEN_SCALE_FACTORS, GDK_SCALE and GDK_DPI_SCALE and then getting various weird bugs rather than telling the DPI and scale factor properly via Xresources and XSETTINGS There isn't a "properly" that works. We have this huge regression *because* someone removed GDK_SCALE
There is, that's how gnome-settings-daemon and mate-settings-daemon do set the settings.
Git commit a2e0cb9f8c95bcb5a9510c519e34673c56182be0 by Fushan Wen, on behalf of Luca Bacci. Committed on 21/02/2023 at 05:03. Pushed by fusionfuture into branch 'master'. Add support for XWayland client scaling This is very important e.g for Chromium or Electron apps. This MR does the following: * Renames the `ConfigValueProvider::globalScaleFactor()` method to `x11GlobalScaleFactor()` * Removes the `ConfigValueProvider::globalScaleFactorAsPercent()`, `ConfigValueProvider::globalScaleFactorFloor()` methods as those are now useless * The global scale factor for XWayland apps is read from `kwinrc` under the `Xwayland` group. * Read the base `Xft.dpi` resource value from the `kdeglobals` config file FIXED-IN: 5.27.1 M +1 -9 kded/config_editor/xsettings.cpp M +0 -1 kded/config_editor/xsettings.h M +13 -18 kded/configvalueprovider.cpp M +8 -4 kded/configvalueprovider.h M +21 -29 kded/gtkconfig.cpp https://invent.kde.org/plasma/kde-gtk-config/commit/a2e0cb9f8c95bcb5a9510c519e34673c56182be0
Git commit 2201885bed9d04c288b74a7fd894f6cb5c68b0ae by Fushan Wen, on behalf of Luca Bacci. Committed on 21/02/2023 at 05:03. Pushed by fusionfuture into branch 'Plasma/5.27'. Add support for XWayland client scaling This is very important e.g for Chromium or Electron apps. This MR does the following: * Renames the `ConfigValueProvider::globalScaleFactor()` method to `x11GlobalScaleFactor()` * Removes the `ConfigValueProvider::globalScaleFactorAsPercent()`, `ConfigValueProvider::globalScaleFactorFloor()` methods as those are now useless * The global scale factor for XWayland apps is read from `kwinrc` under the `Xwayland` group. * Read the base `Xft.dpi` resource value from the `kdeglobals` config file FIXED-IN: 5.27.1 (cherry picked from commit a2e0cb9f8c95bcb5a9510c519e34673c56182be0) M +1 -9 kded/config_editor/xsettings.cpp M +0 -1 kded/config_editor/xsettings.h M +13 -18 kded/configvalueprovider.cpp M +8 -4 kded/configvalueprovider.h M +21 -29 kded/gtkconfig.cpp https://invent.kde.org/plasma/kde-gtk-config/commit/2201885bed9d04c288b74a7fd894f6cb5c68b0ae
It seems like this did not fix it for me, after updating to 5.27.1 (and now 5.27.2) the problem is still persists. It actually got only more unpredictable, sometimes the apps scale correctly even on multiple screens with different dpi, and sometimes after a reboot it just wouldn't work regardless of the settings or environment variables. Even worse, now even on the internal screen alone non-Qt apps just wouldn't scale at all, regardless of global scaling factor and legacy scaling option I choose. This makes the system unusable. I tried to follow the procedure described in the bug fix/merge request and I don't see any local configs like `--force-device-scale-factor` or `GDK_SCALE`. I suspect it might be a local problem on my system since the fix seems to have worked for everyone else, but I don't understand what could be the source of it.
Thanks for the report! Let's see... 1. Make sure you have an xsettings service running in your system. Which distribution are you using? E.g for Arch Linux see https://wiki.archlinux.org/title/Xsettingsd In addition, could you open a terminal and paste here the output of ps a | grep -i xsettings 2. Open Systems Settings > Appearance > Fonts. Do you have the Force Font DPI option turned on and set to some value other than 96? If so your issue is actually https://bugs.kde.org/466463 Thanks!
You can check Xft.dpi from xrdb -query and Xft/DPI + Gdk/UnscaledDPI from dump_xsettings from the xsettingsd package
(In reply to Luca Bacci from comment #35) > Thanks for the report! Let's see... > > 1. Make sure you have an xsettings service running in your system. Which > distribution are you using? E.g for Arch Linux see > https://wiki.archlinux.org/title/Xsettingsd In addition, could you open a > terminal and paste here the output of > > ps a | grep -i xsettings > > 2. Open Systems Settings > Appearance > Fonts. Do you have the Force Font > DPI option turned on and set to some value other than 96? If so your issue > is actually https://bugs.kde.org/466463 > > Thanks! You are right! I am on Arch, and xsettings is not running (so no output in ps grep) neither xsettingsd.service. It was mentioned in https://bugs.kde.org/show_bug.cgi?id=466463#c2 that sometimes it decides no to run, which would explain the randomness I observe after reboots. And yes I have forced font dpi to 192 to have 2x scaling on a 4k screen, thanks for pointing to the issue! And thank you for working on this issue, let's hope the fix in https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/63?commit_id=687e58cbe87f2f800801d0d14fd1db9bf69a0522#4bee960223079fa87842113b7c0d5d2d0830f497 gets merged soon!
(In reply to Ilya Fedin from comment #36) > You can check Xft.dpi from xrdb -query and Xft/DPI + Gdk/UnscaledDPI from > dump_xsettings from the xsettingsd package Xft.dpi is 192, Xft/DPI is 196608 and Gdk/UnscaledDPI is 98304 (which are 192 and 96 respectively, when divided by 1024).
JFYI the correct way to do scaling on Wayland is by using the scaling slider on the Display & Monitor page. Explicitly changing the font DPI alone is not recommended as it will cause things to scale unevenly and break the size relationships between items. It will likely be removed in Plasma 6.
(In reply to Nate Graham from comment #39) > JFYI the correct way to do scaling on Wayland is by using the scaling slider > on the Display & Monitor page. Explicitly changing the font DPI alone is not > recommended as it will cause things to scale unevenly and break the size > relationships between items. It will likely be removed in Plasma 6. I know that from the tooltip of the font DPI option, and I would love to not have to use it and have everything scale according to the global option. But for me it was always the *only* way to make things work. On wayland UI fonts would just not scale at all while the rest of the system would be the correct size according to the global option, so I had to force the font dpi to match the text to the rest of the UI. I assumed that it was just an intended workaround for a wayland bug or missing feature. Having font dpi and global scaling set, everything was scaling perfectly and looking great (up until 5.27).
Using the scaling slider on Wayland automatically sets the font DPI internally to the correct value, or at least it's supposed to. Is it possible you had previously forced the font DPI to something lower, and then later when you started scaling using the slider, it wasn't able to override the previously-overridden value? Either way, this is all quite beside the point of the original bug report, and I'd appreciate it if you could submit a new one about that scaling issue. We don't want your setup to break once we remove the Force Font DPI setting in Plasma 6. Thanks!
(In reply to Nate Graham from comment #41) > Using the scaling slider on Wayland automatically sets the font DPI > internally to the correct value, or at least it's supposed to. Is it > possible you had previously forced the font DPI to something lower, and then > later when you started scaling using the slider, it wasn't able to override > the previously-overridden value? > > Either way, this is all quite beside the point of the original bug report, > and I'd appreciate it if you could submit a new one about that scaling > issue. We don't want your setup to break once we remove the Force Font DPI > setting in Plasma 6. Thanks! I never had the DPI forced to anything lower, because on my 4k laptop screen I need 2x scaling (192 dpi). The slider always stays at the default 100% (which makes the correct scaling on the 4k screen on wayland except for fonts), except if a FHD screen is connected. Maybe the slider doesn't set the font DPI if it is left at the default 100%? Anyways, will submit the another bug report! Thanks for the help!