| Summary: | When attempting to resize an XWayland window, it enters a semi-unresponsive state for several seconds before regular functionality is subsequently restored. | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Naxdy <xnaxdy> |
| Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | nate, vlad.zahorodnii, xaver.hugl |
| Priority: | NOR | Keywords: | regression |
| Version: | 6.0.5 | ||
| Target Milestone: | --- | ||
| Platform: | NixOS | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/83fc98239120b544573b6c07084325c86e041dff | Version Fixed In: | 6.1.1 |
| Sentry Crash Report: | |||
|
Description
Naxdy
2024-06-08 18:59:22 UTC
With current git master, cannot reproduce with any of my XWayland using apps, FWIW. What GPU hardware are you using here? I'm using an AMD 7900 XTX, my wife can also reproduce with an AMD 6750 XT. Which version of XWayland did you test with? We're running 24.1.0 Also 24.1.0 here. My GPU is an Intel HD620 (integrated) from the 10th gen CPU family. Maybe the issue is AMD-specific? I've never seen this on AMD either. What output scale and Xwayland scaling settings are you using? Someone in #kwin found a way for me to be able to reproduce the issue on my system (225% screen scale, XWayland apps scale themselves): Open a video in VLC and resize the window from the right screen edge *very very slowly*, like one pixel at a time. Eventually it gets stuck in the way described in this bug report. My wife and I are in 100% scale, apps apply scaling by themselves. Perhaps the latter is the root cause of the issue? The root cause is that some logical geometry changes may not result in device geometry changes. In those cases, kwin should not send an xsync request otherwise resizing will be blocked for 10s. I know what breaks it, I think we will be able to get something for 6.1.1 A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5889 Git commit 21a45c2700906ef7843cee93d7fdab77ee4e9d35 by Vlad Zahorodnii. Committed on 13/06/2024 at 08:34. Pushed by vladz into branch 'master'. Avoid sending X11 sync request if new logical geometry doesn't change the device geometry There are two mechanisms to throttle ConfigureNotify events during interactive resize: - either using XSync - or by a dummy QTimer The QTimer approach is pretty straightforward: the wm configures the window, blocks the interactive resize operation and arms a timer to unblock it some time later in the future. With the xsync approach, the wm sends an xsync request, makes a call to XConfigureWindow(), and blocks interactive resize until the xsync request is acked by the client. When the client sees the ConfigureNotify event, it is going to repaint and ack the xsync request. When the xsync request is acked, the wm will apply new geometry and unblock interactive resize. After the scaling changes, the logical geometry can have some fractional part, which gets rounded when configuring the X windows. Due to that, it's possible to encounter the case where the logical geometry changes, but the native/device geometry does not due to std::round(). In that case, the wm should not send an xsync request because the client won't ack it because the device geometry has not changed. M +18 -4 src/utils/xcbutils.h M +16 -7 src/x11window.cpp https://invent.kde.org/plasma/kwin/-/commit/21a45c2700906ef7843cee93d7fdab77ee4e9d35 Git commit 83fc98239120b544573b6c07084325c86e041dff by Vlad Zahorodnii. Committed on 13/06/2024 at 08:46. Pushed by vladz into branch 'Plasma/6.1'. Avoid sending X11 sync request if new logical geometry doesn't change the device geometry There are two mechanisms to throttle ConfigureNotify events during interactive resize: - either using XSync - or by a dummy QTimer The QTimer approach is pretty straightforward: the wm configures the window, blocks the interactive resize operation and arms a timer to unblock it some time later in the future. With the xsync approach, the wm sends an xsync request, makes a call to XConfigureWindow(), and blocks interactive resize until the xsync request is acked by the client. When the client sees the ConfigureNotify event, it is going to repaint and ack the xsync request. When the xsync request is acked, the wm will apply new geometry and unblock interactive resize. After the scaling changes, the logical geometry can have some fractional part, which gets rounded when configuring the X windows. Due to that, it's possible to encounter the case where the logical geometry changes, but the native/device geometry does not due to std::round(). In that case, the wm should not send an xsync request because the client won't ack it because the device geometry has not changed. (cherry picked from commit 21a45c2700906ef7843cee93d7fdab77ee4e9d35) M +18 -4 src/utils/xcbutils.h M +16 -7 src/x11window.cpp https://invent.kde.org/plasma/kwin/-/commit/83fc98239120b544573b6c07084325c86e041dff |