Bug 489016 - [wayland] Showing and hiding titlebar and frames on a scaled display will cause XWayland windows to move diagonally by about 1px every time
Summary: [wayland] Showing and hiding titlebar and frames on a scaled display will cau...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: decorations (show other bugs)
Version: 6.1.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-06-23 02:56 UTC by Eamonn Rea
Modified: 2024-07-02 21:22 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 6.2.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eamonn Rea 2024-06-23 02:56:08 UTC
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
Comment 1 Eamonn Rea 2024-06-23 13:32:17 UTC
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.
Comment 2 Vlad Zahorodnii 2024-06-27 11:35:56 UTC
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?
Comment 3 Vlad Zahorodnii 2024-06-28 06:04:03 UTC
.
Comment 4 Eamonn Rea 2024-06-28 20:23:14 UTC
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.
Comment 5 Bug Janitor Service 2024-07-02 09:12:46 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6030
Comment 6 Vlad Zahorodnii 2024-07-02 11:33:22 UTC
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
Comment 7 Eamonn Rea 2024-07-02 21:22:26 UTC
Super cool, thank you for fixing it so quickly!