| Summary: | With fractional scale factors on Wayland, Zoom window enlarges continuously without user interaction | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Iyán Méndez Veiga <me> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bizyaev, fanzhuyifan, kde, nate, rronnander |
| Priority: | HI | Keywords: | qt6, wayland |
| Version: | 5.93.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=483605 | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/5af86d18f406da03d194c464ac63bbb600aebc89 | Version Fixed In: | 6.0.3 |
| Sentry Crash Report: | |||
|
Description
Iyán Méndez Veiga
2024-02-17 12:01:55 UTC
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 |