SUMMARY Toggling the window titlebar and frames of an XWayland application on a scaled display (I am using 150% scaling on my PC and 140% scaling on my laptop), such as by using a shortcut that you can hold down to repeat. will cause the window to shift diagonally by about 1px each time. In my testing this has cause the window to either move diagonally up and to the left, or diagonally down and to the right, but other combinations may exist as well. I am not sure what influences the direction that the windows move, perhaps however the coordinates are being rounded. This *only* affects XWayland applications and only if they are windowed and not maximised. A maximised XWayland application (such as Steam) or a fullscreen XWayland application (such as a game) is not impacted by this. Holding down the shortcut is not required for this, but it is the fastest way to toggle the window decorations and to see visually the movement. It is worth noting that I only found one XWayland application that was unaffected, and that was the Steam Client. I thought that maybe this only affected Qt-based XWayland windows then, but games running via Wine also exhibit this behaviour (games are my most common XWayland use-case which is the only reason I mention them). I could be wrong but perhaps this is related to some fractional scaling weirdness and the rounding of pixels (which should be fixed with fractional-scale-v2)? Possibly related in that case: Bug 459373. STEPS TO REPRODUCE 1. Have an XWayland that has a traditional titlebar and frame, such as the Dolphin File Manager running with XWayland using `QT_QPA_PLATFORM=xcb dolphin` a. You can verify when a program is using XWayland with xeyes 2. Have a keyboard shortcut bound to toggle the Window Titlebar and Frame (can be set under Shortcuts -> KWin -> "Toggle Window Titlebar and Frame") 3. Put the window onto a scaled display. 4. Hide the titlebar and frame, the shortcut will cause the window to drift OBSERVED RESULT Many XWayland windows will drift by about 1px each time if you toggle their window decorations. There is at least one exception, the Steam Client, but every other tested XWayland window did exhibit this behaviour (including some KDE apps like Dolphin forced to run with XWayland) EXPECTED RESULT XWayland windows should not drift and should behave the same as Wayland windows. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Did not test X11 to see if this is just a bug with X11 in general and not spe
I cannot reproduce this on my laptop with just a single screen connected, so perhaps this is specific to display configurations with one scaled display and at least one regular display? My Desktop always has multiple monitors connected so it is most easily reproducible there.
Can you share the geometry of dolphin window on your PC? Type "kwin" in krunner, click "Open KWin debug console" and expand dolphin entry in the windows tab. Then look for bufferGeometry, clientGeometry, and frameGeometry. Also what window decoration settings do you use?
.
This is the geometry of the Dolphin window under X11 windows, with Dolphin being run with `QT_QPA_PLATFORM=xcb dolphin`. bufferGeometry: 895.333,1329.33 1376x919.333 clientGeometry: 895.333,1329.33 1376x919.333 frameGeometry: 894,1296 1379.33x954.667 At first I manually entered these, as I didn't realise double-clicking on the entry in the KWin Debug Console would copy them over. As for window decoration settings, I use standard Breeze Dark decorations, with Button Size set to Large. I don't believe I have any other esoteric settings, at least nothing that has changed in the last few years.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6030
Git commit 84e3ff88c3337db72de7458ff8c1500c0d3e11c3 by Vlad Zahorodnii. Committed on 02/07/2024 at 11:25. Pushed by vladz into branch 'master'. Round X window gravity adjustment Qt applications use Static window gravity by default. This means that if a window decoration is created, the client window should remain at the same position in the global coordinate space. To do that, X11Window needs to move the frame geometry by (-borderLeft(), -borderTop()). On the other hand, after making X11Window::framePosToClientPos() round the window borders, the client window can end up being moved more than expected when applying the gravity adjustment. This change makes X11Window also round the gravity adjustment so the math is consistent there and in the framePosToClientPos() function. M +16 -16 src/x11window.cpp https://invent.kde.org/plasma/kwin/-/commit/84e3ff88c3337db72de7458ff8c1500c0d3e11c3
Super cool, thank you for fixing it so quickly!