Created attachment 139558 [details] Sample application that prints window scaling SUMMARY When using kwin + wayland, gtk applications report a bogus display scaling. STEPS TO REPRODUCE 1. Go to system settings > display configuration 2. Set monitor scale to 200% 3. Run the attached application OBSERVED RESULT "1" instead of the expected "2" is printed. EXPECTED RESULT "2" is printed, as it happens if you do the same on X11 SOFTWARE/OS VERSIONS Operating System: Fedora 34 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 Kernel Version: 5.12.10-300.fc34.x86_64 OS Type: 64-bit Graphics Platform: Wayland ADDITIONAL INFORMATION This causes Firefox to detect the wrong monitor scaling and appear too tiny, when ran with native wayland support rather than via XWayland.
the test app doesn't print anything.
Can you please run the test app with WAYLAND_DEBUG=1 and post the output here?
(In reply to Vlad Zahorodnii from comment #1) > the test app doesn't print anything. Saving the attachment as a python file and running it on a terminal definitely should print the window scale factor to stdout, but sure, will run it with WAYLAND_DEBUG asap, thanks for taking a look.
Created attachment 139565 [details] WAYLAND_DEBUG=1 output (As requested)
Created attachment 139566 [details] WAYLAND_DEBUG=1 output on GNOME set_buffer_scale calls are different
FWIW I see some similar stuff in regular KDE apps, in the sense that I need to set the font size in the font settings to twice the size I want for text to be the right size (so the font settings seem to not account for monitor scale either).
Ok, so this is weird. If I restart my computer and just start a Plasma+Wayland session, then stuff works as expected. If at some point I have started a plasma X11 session before (even though I log out and restart with wayland) then I can repro all this weirdness.
>set_buffer_scale calls are different They are on different surfaces surface 25 is the cursor. surface 30 is the window. Everything from our side look correct. We potentially call wl_surface@30.enter(wl_output@6) at different points to Gnome. That code is querying the scale before the client has been told which output the window is on. Please reopen if you can name something specific that's wrong our side based on that output
Created attachment 139570 [details] WAYLAND_DEBUG=1 output after a restart This is the WAYLAND_DEBUG=1 output after a restart on Plasma, which behaves correctly. So there's some inconsistency on Plasma depending on whether an X11 session has been started before or not. That looks clearly like a bug to me (not sure how prioritary, but definitely threw me off).
(Reopening per the above: Maybe it's known, maybe it's not important enough to fix, but it does look pretty broken to me fwiw)
>So there's some inconsistency on Plasma depending on whether an X11 session has been started before or not Aha! That might be a clue. Is the "env" different between the two cases? (can you just upload the diff please) On X we'll have exported something to set the scale On Wayland we don't export anything as we have wayland communicating it
Created attachment 139572 [details] env difference Spot on, indeed there are two variables that explain this: ``` +GDK_DPI_SCALE=0.5 +GDK_SCALE=2 ```
Created attachment 139573 [details] env difference between x11 and wayland-bad env Yeah, it seems there are a bunch of env changes that starting an x11 Plasma session causes that starting a wayland session doesn't undo.
After going to a wayland session from an x11 session, even a restart, the monitor scale needs to get reset as well from the system settings (even though it is still reported as 200%). Going back to any other scale then back to 200% does cause things to get scaled properly again. So perhaps that's the root of the problem.
\o/ I will patch our startup to explicitly unset these on wayland login. Thanks
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/943
Git commit 4ef92d8c9bba5429bf85c521bc962f105692c4ce by David Edmundson. Committed on 05/07/2021 at 23:05. Pushed by davidedmundson into branch 'master'. Set GDK scale explictily on wayland On wayland we don't want to use the env vars as we send the scale via wl_output scale. If a user logs into X first we set these in our activation env to a scaled value. If they then log into wayland afterwards they are still set. Calling qunsetenv won't work as then we won't remove them from the activation env. Arguably it's working round a bug, but we don't have other options. M +2 -0 startkde/startplasma-wayland.cpp https://invent.kde.org/plasma/plasma-workspace/commit/4ef92d8c9bba5429bf85c521bc962f105692c4ce
Git commit 14cd19138cd514ea753a842d01bd2265ee8ad0b8 by Nate Graham, on behalf of David Edmundson. Committed on 08/07/2021 at 01:09. Pushed by ngraham into branch 'Plasma/5.22'. Set GDK scale explictily on wayland On wayland we don't want to use the env vars as we send the scale via wl_output scale. If a user logs into X first we set these in our activation env to a scaled value. If they then log into wayland afterwards they are still set. Calling qunsetenv won't work as then we won't remove them from the activation env. Arguably it's working round a bug, but we don't have other options. (cherry picked from commit 4ef92d8c9bba5429bf85c521bc962f105692c4ce) M +2 -0 startkde/startplasma-wayland.cpp https://invent.kde.org/plasma/plasma-workspace/commit/14cd19138cd514ea753a842d01bd2265ee8ad0b8