Bug 422578

Summary: Window appears in the top-left corner of the screen with >100% scale factor on X11 when using PLASMA_USE_QT_SCALING=1
Product: [Plasma] krunner Reporter: Nate Graham <nate>
Component: generalAssignee: Nate Graham <nate>
Status: RESOLVED FIXED    
Severity: normal CC: alexander.lohnau, benjamin.port, mathias.ciliberto, philipp.reichmuth, plasma-bugs
Priority: VHI Keywords: regression
Version: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In: 5.19.2
Sentry Crash Report:
Bug Depends on:    
Bug Blocks: 356446    
Attachments: KRunner window in top left corner

Description Nate Graham 2020-06-07 13:44:34 UTC
Created attachment 129122 [details]
KRunner window in top left corner

Everything KDE from git master with Qt 5.15 on openSUSE Tumbleweed.


SUMMARY
None of the power/session actions work for me.


STEPS TO REPRODUCE
1. Set 200% or 250% scale factor in KScreen KCM
2. Reboot
3. Open KRunner


It appears in the top-left corner of the screen. See attached screenshot.

The problem does not appear on Wayland.
Comment 1 Alexander Lohnau 2020-06-07 14:39:13 UTC
Can't reproduce on KDE Neon Unstable with Qt 5.14.2.
Comment 2 Nate Graham 2020-06-07 19:02:40 UTC
Hmm, could be a Qt regression. :/
Comment 3 Benjamin Port 2020-06-08 06:51:15 UTC
I can't reproduce it with Qt 5.15 and master
Comment 4 phrxmd 2020-06-15 16:13:56 UTC
*** Bug 422976 has been marked as a duplicate of this bug. ***
Comment 5 phrxmd 2020-06-15 16:21:55 UTC
I'm seeing the same thing (reported as duplicate in https://bugs.kde.org/show_bug.cgi?id=422976 because I kept looking for "HiDPI" in my bugtracker search.).

Alexander reports that he doesn't see this issue on KDE Neon with the same device and scaling; that's possible. I migrated to OpenSUSE from Kubuntu with Plasma 5.18 and Qt 5.12, where I also didn't have this issue. I then tried to move my working HiDPI display configuration to OpenSUSE with Plasma 5.19 and Qt 5.15. During the transition I had to set PLASMA_USE_QT_SCALING=1, which I didn't under Kubuntu. I'm not sure whether that is because Kubuntu doesn't need it, or whether it silently sets it itself. After this, I am now seeing this behaviour with KRunner and a similar issue with Yakuake, whereas before it was fine.

I assume that could have to do with how there are too many degrees of freedom in the different ways to try and achieve a good-looking UI on HiDPI screens (Global scaling, QT_SCALE_FACTOR, QT_AUTO_SCREEN_SCALE_FACTOR, Force font DPI, QT_ENABLE_HIGHDPI_SCALING, Xft.dpi and so on). What would be the best way to provide more information?
Comment 6 phrxmd 2020-06-15 18:13:48 UTC
Addendum: the related Yakuake issue where I'm seeing similar behaviour seems to be bug 389448. Difference: adding & removing a virtual desktop does not make the problem go away with KRunner as it does with Yakuake
Comment 7 Mathias C. 2020-06-17 12:01:44 UTC
I have the same issue with Archlinux, Kde Plasma 5.19, KDE Framework 5.71.0, QT 5.15, under X11. Actually, in my case, KRunner appears on the left but with an offset from the very left side of the screen (similarly to https://bugs.kde.org/show_bug.cgi?id=422976)
Comment 8 Nate Graham 2020-06-17 14:25:28 UTC
I have a feeling we're going to start getting a lot of duplicates of this soon. :(

Does everyone experiencing the issue have Qt 5.15?
Comment 9 Alexander Lohnau 2020-06-17 14:52:19 UTC
@ngraham

Have you tried installing a previous version the KRunner executable (just the view.cpp file)? I remember there being a lot of work done regarding the positioning.

For instance https://invent.kde.org/plasma/plasma-workspace/-/commit/731a190810440726f2db252b3a935648346f4a12.
Comment 10 Nate Graham 2020-06-17 15:58:04 UTC
Yep, that's the one. Reverting that commit fixes the issue for me.
Comment 11 Nate Graham 2020-06-17 20:53:37 UTC
Working on this. Seems like the problem is that the DBus reply gives us a QRect that's in scaled pixels while shownOnScreen->availableGeometry() gives us raw pixels, and the positioning algorithm only works with physical pixels. At 100% scale, these are identical, so there's no bug. At greater than 100% scale, the calculation will be off by a magnitude that increases as the scale does.
Comment 12 Nate Graham 2020-06-17 21:51:50 UTC
Further investigation: this mismatch between scaled and unscaled coordinates only happens on X11. On Wayland everything uses scaled coordinates and it all works properly. But on X11, the DBus reply gives is scaled pixels while the rest of the code is in unscaled pixels.
Comment 13 Nate Graham 2020-06-17 22:11:48 UTC
Final piece of potentially interesting information: this only happens with PLASMA_USE_QT_SCALING=1 on X11. So I guess this could be considered another blocker to enabling that.
Comment 14 Bug Janitor Service 2020-06-17 22:22:03 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/91
Comment 15 Nate Graham 2020-06-18 15:25:40 UTC
Git commit 0f8c6c3a660d9778b04722f6a7319224205e3aa0 by Nate Graham, on behalf of David Edmundson.
Committed on 18/06/2020 at 15:22.
Pushed by ngraham into branch 'Plasma/5.19'.

Fix KRunner positioning on X11 with High DPI and Qt scaling on Plasma

When using Qt scaling, we want to adois mising scaled and unscaled
geometry spaces, as this leads to poitioning issues.
FIXED-IN: 5.19.2

M  +4    -2    krunner/main.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/0f8c6c3a660d9778b04722f6a7319224205e3aa0
Comment 16 Benjamin Port 2020-06-22 08:47:02 UTC
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/107

If someone can test this fix, and confirm it fix the issue, thanks