SUMMARY This is a funny issue. I don't know if it's caused by Qt 6.7 or by some changes in Plasma 6. I also remember having a similar issue with Inkscape in the past before it started to work correctly as a native Wayland app, so probably this only affects XWayland apps. When opening certain windows (e.g., the "Share screen" window during a call), they enlarge continuously and indefinitely without user interaction. It's hard to describe so I will try to record a video later. The window first starts to expand to the right of the desktop. Once it reaches the end of the screen, it starts to push the window to the left so it gives the impression the app is expanding to the left. When all the width is used, the window continues to expand to the right outside the screen range. STEPS TO REPRODUCE 1. Open Zoom (probably other XWayland apps suffer from this issue too) 2. Start a call 3. Open Share screen window OBSERVED RESULT What is described above, the window continuously expands its width to the right. EXPECTED RESULT Window has a fixed size unless the user manually changes it SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.93.0 KDE Frameworks Version: 5.249.0 Qt Version: 6.7.0 Kernel Version: 6.7.4-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 8 × 11th Gen Intel® Core™ i5-1135G7 @ 2.40GHz Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics Manufacturer: LENOVO Product Name: 20XYCTO1WW System Version: ThinkPad X1 Yoga Gen 6
Here is a video of the issue: https://drive.switch.ch/index.php/s/HKnY7QNkw8BP69m
What scale factor do you use? Is it reproducible with x1?
(In reply to Vlad Zahorodnii from comment #2) > What scale factor do you use? Is it reproducible with x1? 125%, and I cannot reproduce on X11 with global scale set to 100% or 125%.
By "x1", I meant a scale factor of 1
(In reply to Vlad Zahorodnii from comment #4) > By "x1", I meant a scale factor of 1 Sorry, my bad. No, also in Wayland with 100% I cannot reproduce the issue. It only happens with certain fractional scale levels. For example, 125% triggers changing the width, while 150% triggers changing the height, although that finish early because I guess the window has some hardcoded maximum height. Here is a new video testing different scale levels: https://drive.switch.ch/index.php/s/R04sQcItuKyc83S The video also shows two other (minor) issues: 1. Two mouses are recorded in Wayland 2. The blue line in the display configuration for some scales is a thin bottom line, but others is a grading using all the rectangle space.
> 2. The blue line in the display configuration for some scales is a thin > bottom line, but others is a grading using all the rectangle space. This I have reported in more detail in Bug 481550
I was unable to sort out having a zoom account, could you test something for me - create a window rule for zoom - force the title or something so you know the rule is matching - set "obey geometry restrictions" and force it to no See if the bug still manifests
(In reply to David Edmundson from comment #7) > I was unable to sort out having a zoom account, could you test something for > me > > - create a window rule for zoom > - force the title or something so you know the rule is matching > - set "obey geometry restrictions" and force it to no > > See if the bug still manifests The bug still manifests. I was not sure if the rule was matching so I tested with settings fullscreen force set to yes. In that case, all Zoom windows are indeed fullscreen, including the share screen one (without the bug in this case). But with "obey geometry restrictions" set to no, I still have the same issue.
FWIW I can reproduce with 125% scale, 2560x1600 screen. Qt 6.7, arch linux, wayland, zoom 5.17.10-1. The 125% scale seems quite important, since I can't reproduce if I use 115%, 120%, 130%, or 135% scale.
*** Bug 483605 has been marked as a duplicate of this bug. ***
(In reply to fanzhuyifan from comment #10) > *** Bug 483605 has been marked as a duplicate of this bug. *** I can also reproduce with 250%, as reported in 483605.
As mentioned in Bug 483605, a necessary condition is checking Legacy Applications Apply Scaling themselves.
Currently toXNative [0] rounds halfs away from 0, and we get increasing window sizes. If we change it to round halfs towards 0, we get decreasing window sizes. If we change it to round halfs to even, the problem seems to disappear. It seems the scale 1.25 is special because it can exactly generate integer + 0.5 when multiplied by an integer. I have no idea what the root cause of the problem is though. (This hypothesis is consistent with the problem also being reported for scale=1.5 and and scale=2.5). [0] https://invent.kde.org/plasma/kwin/-/blob/master/src/utils/xcbutils.cpp?ref_type=heads#L624
(In reply to fanzhuyifan from comment #13) > Currently toXNative [0] rounds halfs away from 0, and we get increasing > window sizes. If we change it to round halfs towards 0, we get decreasing > window sizes. If we change it to round halfs to even, the problem seems to > disappear. > > It seems the scale 1.25 is special because it can exactly generate integer + > 0.5 when multiplied by an integer. I have no idea what the root cause of the > problem is though. (This hypothesis is consistent with the problem also > being reported for scale=1.5 and and scale=2.5). > > [0] > https://invent.kde.org/plasma/kwin/-/blob/master/src/utils/xcbutils. > cpp?ref_type=heads#L624 The actual problem seems to be that the code is rounding both frame size and client size to have integral XNative sizes. However, their difference, the border size, does not always have integral XNative sizes [1]. Hence, we get cycles of rounding, and in this particular case, this leads to infinitely growing window sizes when we round up. [1] https://invent.kde.org/plasma/kwin/-/blob/master/src/x11window.cpp?ref_type=heads#L2834
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5489
Git commit 111657ad04e7627d6e3c7b345a48670459cdeacc by Yifan Zhu. Committed on 20/03/2024 at 21:24. Pushed by fanzhuyifan into branch 'master'. x11window: round border size to integral XNative units Both frameSize and clientSize are rounded to integral XNative units. So their difference must also be rounded to integral XNative units. Otherwise we get cycles of rounding that can cause growing window sizes. M +5 -0 src/utils/xcbutils.cpp M +7 -0 src/utils/xcbutils.h M +14 -8 src/x11window.cpp https://invent.kde.org/plasma/kwin/-/commit/111657ad04e7627d6e3c7b345a48670459cdeacc
Git commit 5af86d18f406da03d194c464ac63bbb600aebc89 by Yifan Zhu. Committed on 20/03/2024 at 21:37. Pushed by fanzhuyifan into branch 'Plasma/6.0'. x11window: round border size to integral XNative units Both frameSize and clientSize are rounded to integral XNative units. So their difference must also be rounded to integral XNative units. Otherwise we get cycles of rounding that can cause growing window sizes. (cherry picked from commit 111657ad04e7627d6e3c7b345a48670459cdeacc) M +5 -0 src/utils/xcbutils.cpp M +7 -0 src/utils/xcbutils.h M +14 -8 src/x11window.cpp https://invent.kde.org/plasma/kwin/-/commit/5af86d18f406da03d194c464ac63bbb600aebc89
This fixes Godot for me with Qt 6.6.2