Bug 488223 - When attempting to resize an XWayland window, it enters a semi-unresponsive state for several seconds before regular functionality is subsequently restored.
Summary: When attempting to resize an XWayland window, it enters a semi-unresponsive s...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: 6.0.5
Platform: NixOS Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2024-06-08 18:59 UTC by Naxdy
Modified: 2024-06-13 23:17 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Naxdy 2024-06-08 18:59:22 UTC
SUMMARY
When attempting to resize an XWayland window, it enters a semi-unresponsive state for several seconds during which it cannot be moved or resized, but is otherwise interactive (i.e. window contents respond to user interaction like mouse clicks). After a few seconds have elapsed, the window becomes fully responsive again, and remains in that state until closed.

STEPS TO REPRODUCE
1. Open an XWayland window (tested with VLC and a few others, but anything should work)
2. Attempt to resize the window, either by dragging from one of its corners, or by using the Meta + Right Click shortcut.

OBSERVED RESULT
The window resizes initially, then stops. Further attempts to move or resize the window fail for several seconds.

EXPECTED RESULT
The window resizes as expected, without interruption.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: NixOS
(available in About System)
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.1

ADDITIONAL INFORMATION
This has not been the case for all of Plasma 6, but I'm not sure of the exact version this appeared on. Sometime after 6.0.3 would be my best guess.
Comment 1 Nate Graham 2024-06-10 19:19:34 UTC
With current git master, cannot reproduce with any of my XWayland using apps, FWIW.

What GPU hardware are you using here?
Comment 2 Naxdy 2024-06-10 19:21:46 UTC
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
Comment 3 Nate Graham 2024-06-12 14:56:28 UTC
Also 24.1.0 here. My GPU is an Intel HD620 (integrated) from the 10th gen CPU family. Maybe the issue is AMD-specific?
Comment 4 Zamundaaa 2024-06-12 15:32:00 UTC
I've never seen this on AMD either. What output scale and Xwayland scaling settings are you using?
Comment 5 Nate Graham 2024-06-12 15:36:54 UTC
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.
Comment 6 Naxdy 2024-06-12 16:17:05 UTC
My wife and I are in 100% scale, apps apply scaling by themselves. Perhaps the latter is the root cause of the issue?
Comment 7 Vlad Zahorodnii 2024-06-12 20:08:44 UTC
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
Comment 8 Bug Janitor Service 2024-06-12 20:50:05 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5889
Comment 9 Vlad Zahorodnii 2024-06-13 08:45:37 UTC
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
Comment 10 Vlad Zahorodnii 2024-06-13 18:55:16 UTC
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