[kwin] [Bug 488223] When attempting to resize an XWayland window, it enters a semi-unresponsive state for several seconds before regular functionality is subsequently restored.
https://bugs.kde.org/show_bug.cgi?id=488223 Nate Graham changed: What|Removed |Added Version Fixed In|6.2.0 |6.1.1 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488223] When attempting to resize an XWayland window, it enters a semi-unresponsive state for several seconds before regular functionality is subsequently restored.
https://bugs.kde.org/show_bug.cgi?id=488223 Vlad Zahorodnii changed: What|Removed |Added Latest Commit|https://invent.kde.org/plas |https://invent.kde.org/plas |ma/kwin/-/commit/21a45c2700 |ma/kwin/-/commit/83fc982391 |906ef7843cee93d7fdab77ee4e9 |20b544573b6c07084325c86e041 |d35 |dff --- Comment #10 from Vlad Zahorodnii --- 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 -4src/utils/xcbutils.h M +16 -7src/x11window.cpp https://invent.kde.org/plasma/kwin/-/commit/83fc98239120b544573b6c07084325c86e041dff -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488223] When attempting to resize an XWayland window, it enters a semi-unresponsive state for several seconds before regular functionality is subsequently restored.
https://bugs.kde.org/show_bug.cgi?id=488223 Nate Graham changed: What|Removed |Added Version Fixed In||6.2.0 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488223] When attempting to resize an XWayland window, it enters a semi-unresponsive state for several seconds before regular functionality is subsequently restored.
https://bugs.kde.org/show_bug.cgi?id=488223 Vlad Zahorodnii changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Latest Commit||https://invent.kde.org/plas ||ma/kwin/-/commit/21a45c2700 ||906ef7843cee93d7fdab77ee4e9 ||d35 --- Comment #9 from Vlad Zahorodnii --- 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 -4src/utils/xcbutils.h M +16 -7src/x11window.cpp https://invent.kde.org/plasma/kwin/-/commit/21a45c2700906ef7843cee93d7fdab77ee4e9d35 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488223] When attempting to resize an XWayland window, it enters a semi-unresponsive state for several seconds before regular functionality is subsequently restored.
https://bugs.kde.org/show_bug.cgi?id=488223 Bug Janitor Service changed: What|Removed |Added Status|CONFIRMED |ASSIGNED --- Comment #8 from Bug Janitor Service --- A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5889 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488223] When attempting to resize an XWayland window, it enters a semi-unresponsive state for several seconds before regular functionality is subsequently restored.
https://bugs.kde.org/show_bug.cgi?id=488223 --- Comment #7 from Vlad Zahorodnii --- 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 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488223] When attempting to resize an XWayland window, it enters a semi-unresponsive state for several seconds before regular functionality is subsequently restored.
https://bugs.kde.org/show_bug.cgi?id=488223 --- Comment #6 from Naxdy --- My wife and I are in 100% scale, apps apply scaling by themselves. Perhaps the latter is the root cause of the issue? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488223] When attempting to resize an XWayland window, it enters a semi-unresponsive state for several seconds before regular functionality is subsequently restored.
https://bugs.kde.org/show_bug.cgi?id=488223 Nate Graham changed: What|Removed |Added Ever confirmed|0 |1 Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |CONFIRMED --- Comment #5 from Nate Graham --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488223] When attempting to resize an XWayland window, it enters a semi-unresponsive state for several seconds before regular functionality is subsequently restored.
https://bugs.kde.org/show_bug.cgi?id=488223 Zamundaaa changed: What|Removed |Added Status|REPORTED|NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #4 from Zamundaaa --- I've never seen this on AMD either. What output scale and Xwayland scaling settings are you using? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488223] When attempting to resize an XWayland window, it enters a semi-unresponsive state for several seconds before regular functionality is subsequently restored.
https://bugs.kde.org/show_bug.cgi?id=488223 Nate Graham changed: What|Removed |Added CC||vlad.zahorod...@kde.org, ||xaver.h...@gmail.com --- Comment #3 from Nate Graham --- Also 24.1.0 here. My GPU is an Intel HD620 (integrated) from the 10th gen CPU family. Maybe the issue is AMD-specific? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488223] When attempting to resize an XWayland window, it enters a semi-unresponsive state for several seconds before regular functionality is subsequently restored.
https://bugs.kde.org/show_bug.cgi?id=488223 --- Comment #2 from Naxdy --- 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 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488223] When attempting to resize an XWayland window, it enters a semi-unresponsive state for several seconds before regular functionality is subsequently restored.
https://bugs.kde.org/show_bug.cgi?id=488223 Nate Graham changed: What|Removed |Added CC||n...@kde.org Keywords||regression --- Comment #1 from Nate Graham --- With current git master, cannot reproduce with any of my XWayland using apps, FWIW. What GPU hardware are you using here? -- You are receiving this mail because: You are watching all bug changes.
