Debian Patches
Status for qtwayland-opensource-src/5.15.8-2
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| skip_animated_cursor_test.diff | skip tst_seatv4::animatedCursor that fails in Debian | Dmitry Shachnev <mitya57@debian.org> | not-needed | upstream | 2020-04-30 | |
| 0001-Client-Announce-an-output-after-receiving-more-compl.patch | [PATCH] Client: Announce an output after receiving more complete state Output initialization is not atomic, meaning that the compositor may process a wl_output bind request in one event loop cycle, and the xdg_output_manager.get_xdg_output in another event loop cycle. This means that xdg_output properties may arrive in another wl_output done frame. Prior to xdg-output v3, that wasn't an issue because the compositor is required to send an xdg_output.done event after sending xdg_output properties. Starting with v3, the compositor may choose not to send an xdg_output.done event after sending xdg_output properties. Therefore, as is, QtWayland may announce an output with bad logical geometry or even worse without name assigned by the compositor. Unfortunately, that breaks applications such as plasmashell. Plasma uses output names as a criterion to determine what kind of contents should be displayed on a particular output. In order to fix the initialization sequence, this change makes every QWaylandScreen track processed events. After all required events have been received, the screen can be announced to the rest of Qt. (cherry picked from commit 69ea480f2e53ad4a5bbca78cde044eb8d4c48896) Original Ticket: https://codereview.qt-project.org/c/qt/qtwayland/+/347774 |
Vlad Zahorodnii <vlad.zahorodnii@kde.org> | no | 2021-05-05 | ||
| 0002-Fix-issue-with-repeated-window-size-changes.patch | [PATCH] Fix issue with repeated window size changes Check if the new window size is different from the size requested previously before calling wl_egl_window_resize. It addresses the issue where repeated setGeometry calls between two sizes might not work as expected. The problem occurs when wl_egl_window_get_attached_size does not get the same size that was requested by the previous setGeometry call. If the returned size happened to match the new size instead, we would mistakenly skip the resize. (cherry picked from commit 14d066c61025e548227ccd8d655e80ffa31fa15e) |
Jaeyoon Jung <jaeyoon.jung@lge.com> | no | 2021-02-15 | ||
| 0004-Client-Connect-drags-being-accepted-to-updating-the-.patch | [PATCH] Client: Connect drags being accepted to updating the source drag icon Currently in a multi-process drag and drop when the other client accepts a given mimetype for dropping it calls accept, which is received by the client, but the drag cursor is never updated. Instead the drag cursor was updated in the data_device_enter events which only works if we are operating within one process. The code existed to handle this existed but both the targetChanged signal and the dragSourceTargetChanged were unused. (cherry picked from commit 08e478448a97a440d5a968a5d797f0d7302140c2) |
David Edmundson <davidedmundson@kde.org> | no | 2021-02-09 | ||
| 0005-Client-Disconnect-registry-listener-on-destruction.patch | [PATCH] Client: Disconnect registry listener on destruction If a display outlives a QWaylandClientExtension and a new global is announced we end up delivering an event to a now deleted extension which will crash. (cherry picked from commit c4ba37cd2f8cb81b9438b56ac604fc2f3e45083c) |
David Edmundson <davidedmundson@kde.org> | no | 2021-05-14 | ||
| 0006-Client-Set-XdgShell-size-hints-before-the-first-comm.patch | [PATCH] Client: Set XdgShell size hints before the first commit propagateSizeHints is only called in QWindow we have platform window and minimumSizeHint is then sent. We also need to send existing hints when we create the shell window. Sending them when we apply configure is too late, we need these hints available for the compositor to correctly configure the window. (cherry picked from commit d6e074d0d35221b0fac14c94fc79c98363f2f6c3) |
David Edmundson <davidedmundson@kde.org> | no | 2021-05-03 | ||
| 0007-Fix-build.patch | [PATCH] Fix build 1b5e43a593e917610e6245f7a272ac081c508ba4 relied on a patch that we can't backport. This adds that extra internal boolean backporting just the tiny part of d6ac8cf6. |
David Edmundson <davidedmundson@kde.org> | no | 2021-06-14 | ||
| 0008-Fix-remove-listener.patch | [PATCH] Fix: remove listener Add the operation for removing the listener form listener list (cherry picked from commit 16760280fd04cf70255bab16d9acecad254fdd8f) |
Zhang Liang <zhanglianga@uniontech.com> | no | 2021-02-01 | ||
| 0009-Hook-up-queryKeyboardModifers.patch | [PATCH] Hook up queryKeyboardModifers Can be useful when upon enter a modifiers event is received but no key event so no QKeyEvent is generated. (cherry picked from commit 4fa2baba8181ade4958a94e9531ec4f6919438a9) |
David Redondo <qt@david-redondo.de> | no | 2021-05-26 | ||
| 0011-Correctly-detect-if-image-format-is-supported-by-QIm.patch | [PATCH] Correctly detect if image format is supported by QImageWriter The code queries potential image formats by stripping a mimetype of its 'image/' prefix and making the rest of the mimetype capitalised, such as 'image/png' -> 'PNG'. The problem is that this is then searched for in QImageWriter::supportedImageFormats() by simple equality. The method returns a list of lowercase byte arrays, not uppercase. As the codepath can never match due to checking for an uppercase word in an array of lowercase words, this means that images are effectively always sent as BMP format, even if they should be sent in other formats, such as PNG or JPEG. A simple inspection with GDB (or a qDebug) reveals this: ``` (gdb) p QImageWriter::supportedImageFormats() $31 = {"bmp" = {...}, "bw" = {...}, "cur" = {...}, "eps" = {...}, "epsf" = {...}, "epsi" = {...}, "icns" = {...}, "ico" = {...}, "jp2" = {...}, "jpeg" = {...}, "jpg" = {...}, "pbm" = {...}, "pcx" = {...}, "pgm" = {...}, "pic" = {...}, "png" = {...}, "ppm" = {...}, "rgb" = {...}, "rgba" = {...}, "sgi" = {...}, "tga" = {...}, "tif" = {...}, "tiff" = {...}, "wbmp" = {...}, "webp" = {...}, "xbm" = {...}, "xpm" = {...}} ``` ``` (gdb) p QImageWriter::supportedImageFormats().contains("PNG") $32 = false ``` ``` (gdb) p QImageWriter::supportedImageFormats().contains("png") $33 = true ``` The fix for this is simple: lowercase the remainder of the mimetype, instead of uppercasing it, and we can start hitting the codepath that's supposed to write non-BMP formats. (cherry picked from commit 6072c1dc87e185f30c014f764737ac97b906640f) |
Jan Blackquill <uhhadd@gmail.com> | no | 2021-08-24 | ||
| 0013-Client-Don-t-always-recreate-frame-callbacks.patch | [PATCH] Client: Don't always recreate frame callbacks The main QWaylandWindow method that is executed when handling updates is QWaylandWindow::handleUpdate(). This method always, unconditionally queues a frame callback, regardless of whether any other one is already queued. On some circumstances, e.g. when a window is hidden or completely obscured by other windows, it stops receiving frame callbacks from the compositor. However, QWaylandWindow would continue to request for them, which eventually fills up the Wayland socket, and causes the application to crash. This can be avoided by checking if the platform window is already waiting for a frame callback, before queueing another one. In QWaylandWindow::handleUpdate(), check if mWaitingForFrameCallback is true before queueing frame callbacks, and early return if that's the case. The XDG-shell test needed to be updated for this: The mock compositor is not responding to any frame callbacks, so the window will be unexposed, no longer get paint events and therefore not trigger any commit. This worked by accident before because we were issuing updates quickly enough to reset the timer before it had a chance to unexpose the window. The easiest fix is just to disable the dependency on frame callbacks in this test, since that is clearly not what it's testing. (cherry picked from commit cbc74ba6d7186457d8d07183272e952dee5f34f9) |
Georges Basile Stavracas Neto <gbsneto@gnome.org> | no | 2021-05-27 | ||
| 0014-Client-Always-destroy-frame-callback-in-the-actual-c.patch | [PATCH] Client: Always destroy frame callback in the actual callback It's good hygiene to destroy all frame callbacks. Destroy the frame callback and cleanup the mFrameCallback class member in the callback itself. The callback destruction happens before calling handleFrameCallback() to avoid the theoretical case where another frame callback is queued by handleFrameCallback(), and then immediately destroyed in the callback handler. * asturmlechner 2021-09-27: Conflict resolved from non-backported commit in dev branch: 93058de8d7e7c2f320c22b3bd898aa06cf5babcd (cherry picked from commit 42cdc61a93cf2acb09936aebb5e431fdbc0a26c6) |
Georges Basile Stavracas Neto <gbsneto@gnome.org> | no | 2021-05-27 | ||
| 0016-Wayland-client-use-wl_keyboard-to-determine-active-s.patch | [PATCH] Wayland client: use wl_keyboard to determine active state Commit f497a5bb87270174b8e0106b7eca1992d44ff15d made QWaylandDisplay use the xdgshell's active state for QWindow::isActive(), instead of using wl_keyboard activate/deactivate events. That seems to have been a misunderstanding, since xdgshell activation is only supposed to be used to determine visual appearance, and there is an explicit warning not to assume it means focus. This commit reverts this logic back to listening to wl_keyboard. It adds a fallback when there is no wl_keyboard available to handle activated/deactivated events through xdg-shell, in order to fix QTBUG-53702. windowStates is handled so that we're not using the Xdg hint for anything with QWindowSystemInterface::handleWindowStateChanged or anything where we need to track only having one active. We are still exposing it for decorations, which is the only reason to use the Xdghint over keyboard focus - so you can keep the toplevel active whilst you show a popup. cherry-pick 40036a1b80e5234e6db7d5cbeff122aa7ee13e20 |
=?UTF-8?q?M=C3=A9ven=20Car?= <meven.car@enioka.com> | no | 2021-08-18 | ||
| 0017-Client-do-not-empty-clipboard-when-a-new-popup-windo.patch | [PATCH] Client: do not empty clipboard when a new popup/window is opened If we open a new popup or a window within the same app we have to avoid invalidating selection offer when losing focus, because it's still the same client who has the focus and we might not get a new selection offer by the compositor and therefore we would lose clipboard content. |
Jan Grulich <jgrulich@redhat.com> | no | 2021-07-16 | ||
| 0018-Set-preedit-cursor-when-cursor-equals-to-0.patch | [PATCH] Set preedit cursor when cursor equals to 0 (cherry picked from commit 719a55be13bdadfa659a732755f280e276a894bd) |
Weng Xuetian <wengxt@gmail.com> | no | 2021-12-18 | ||
| 0019-Client-Implement-DataDeviceV3.patch | [PATCH] Client: Implement DataDeviceV3 DataDeviceV2 fixes a leak of DataDevice resources. DataDeviceV3 brings multiple improvements: Action negotiation. The source announces which actions are supported, the target then announces which subset of those action the target supports and a preferred action. After negotiation both the source and target are notified of which action is to be performed. Drag sources are now notified when contents are dropped and when a client has finished with the drag and drop operation. A good test is the draggableicons example in QtBase. (cherry picked from commit 283a2d61d03315495a52d82f356e7cb5292f4bb4) |
David Edmundson <davidedmundson@kde.org> | no | 2021-02-16 | ||
| 0020-Client-Delay-deletion-of-QDrag-object-until-after-we.patch | [PATCH] Client: Delay deletion of QDrag object until after we're done with it In certain cases, most notably when performing drag and drop operations with touch, the QDrag object gets deleted before data_source_send is executed. This then tries to access a deleted data_source, crashing the client. To avoid this, we indicate we want the QDrag object to stay around and then delete it in QWaylandDrag::finishDrag, which with data_device v3 is guaranteed to be called after everyone is done with the data source. (cherry picked from commit 39e3290efa2dd40722fa3322284cae3b01ccedf4) |
Arjen Hiemstra <ahiemstra@heimr.nl> | no | 2021-11-18 | ||
| 0021-Client-Avoid-processing-of-events-when-showing-windo.patch | [PATCH] Client: Avoid processing of events when showing windows The only time we want to dispatch events from the wayland socket is when the application is waiting for external events. Doing so at any other time will cause unpredictable behavior in client code. This caused a crash downstream where we had outputs get altered whilst itterating through outputs, which shouldn't happen. There is no benefit to flushing here, it won't make anything appear faster as we haven't attached the buffer yet. (cherry picked from commit 46ed85a80b28d519cf5887bbdce55d1bf57886c3) |
David Edmundson <davidedmundson@kde.org> | no | 2021-11-14 | ||
| 0022-Handle-registry_global-out-of-constructor.patch | [PATCH] Handle registry_global out of constructor Factory functions in QWaylandDisplay::registry_global() can be overridden. Later, other classes instantiated in the registry_global can support platform specific implementation with inheritance and some factory function. (cherry picked from commit 3793a82038682db77966ea5daf8e75964e4250fe) |
Elvis Lee <kwangwoong.lee@lge.com> | no | 2021-02-18 | ||
| 0023-Connect-flushRequest-after-forceRoundTrip.patch | [PATCH] Connect flushRequest after forceRoundTrip If flushRequest is connected with aboutToBlock, the flushRequest may consumes all events so that processEvents might be blocked in forceRoundTrip. (cherry picked from commit 654a54755138c520c3a41210d8078196e9a2c1bf) |
Elvis Lee <kwangwoong.lee@lge.com> | no | 2021-03-17 | ||
| 0024-Move-the-wayland-socket-polling-to-a-separate-event-.patch | [PATCH] Move the wayland socket polling to a separate event thread New event threads is introduced which calls poll() on the wayland fd, instead of relying on the event dispatcher by using the QSocketNotifier. This allows to call in the proper order the wl_display_prepare_read(), poll() and wl_display_read_events() functions. One thread is responsible for the default queue; when needed, it emit a signal so that the main thread can dispatch the queue. Another thread is responsible for the dedicated queue for frame callbacks; this thread will dispatch events on the thread itself. QWaylandWindow is updated to, instead of each window's dedicated event queue, use this queue for frame callbacks. (cherry picked from commit 92a7904d9651348b0c307e84251c8440c6f75b22) |
Adrien Faveraux <af@brain-networks.fr> | no | 2021-11-26 | ||
| 0028-Fix-crash-if-no-input-method-module-could-be-loaded.patch | [PATCH] Fix crash if no input method module could be loaded (cherry picked from commit 49fb7248f6ab7de046e2179c7861951ea1169e9b) |
Joni Poikelin <joni.poikelin@qt.io> | no | 2022-02-03 | ||
| 0029-Client-Remove-mWaitingForUpdateDelivery.patch | [PATCH] Client: Remove mWaitingForUpdateDelivery Currently, mWaitingForUpdateDelivery is shared between the main thread (doHandleFrameCallback()) and the frame callback event thread (handleFrameCallback()), however the access to it is not synchronized between both threads. On the other hand, QWaylandWindow already ensures not to create a frame callback if there's already one pending. This change removes mWaitingForUpdateDelivery flag because it should be already covered by mWaitingForFrameCallback and to remove unsynchronized shared state between threads. (cherry picked from commit feb1a5c207c13d0bf87c0d8ad039279dbf8cee9e) |
Vlad Zahorodnii <vlad.zahorodnii@kde.org> | no | 2022-02-01 | ||
| 0030-Cursor-position-0-should-still-show-the-cursor.patch | [PATCH] Cursor position == 0 should still show the cursor Otherwise the cursor would be hidden even if preedit is empty. Amends 719a55be13bdadfa659a732755f280e276a894bd (cherry picked from commit 31ae194e295651d9ece03408630d2358acd4f7b4) |
Weng Xuetian <wengxt@gmail.com> | no | 2022-02-08 | ||
| 0031-Update-the-preedit-styling-mapping.patch | [PATCH] Update the preedit styling mapping - None mapping to no style. - Default/Underline mapping to underline. - Highlight/Selection mapping to background color/text color with highlight/highlight text with underline. - Active/Inactive mapping to bold text with underline. - Incorrect mapping to red wave underline. (cherry picked from commit f1fb5d9e568a24e213ee41e82a1142cef56f1098) |
Weng Xuetian <wengxt@gmail.com> | no | 2021-12-22 | ||
| 0032-client-Simplify-round-trip-behavior.patch | [PATCH] client: Simplify round trip behavior The custom event queue was removed in 302d4ffb8549214eb4028dc3e47ec4ee4e12ffbd (2015) so the comment about not being able to use the inbuilt round trip method no longer applies. This fixes a real world problem. Use of a blocking round trip should not process non wayland events. Doing so can lead to misbehaviour client side as things happen out of order. The move to the event thread created several regressions as we now get events before the QGuiApplication is fully constructed. (cherry picked from commit 62646d9122845d7bd9104b610478cebde3e769c7) |
David Edmundson <davidedmundson@kde.org> | no | 2022-02-09 | ||
| 0033-Client-Fix-opaque-region-setter.patch | [PATCH] Client: Fix opaque region setter The rect is in the global coordinate system, while the opaque region must be in the surface local coordinate system. (cherry picked from commit f9425f573b18c0b66fd9ad9c2805e8b8b9a3ec77) |
Vlad Zahorodnii <vlad.zahorodnii@kde.org> | no | 2022-02-19 | ||
| 0034-Use-proper-dependencies-in-compile-tests.patch | [PATCH] Use proper dependencies in compile tests Use the dependencies as found by the "libraries" section instead of relying on them being available in the default location (e.g. "-ldrm"). Additionally, VK_USE_PLATFORM_WAYLAND_KHR requires <wayland-client.h>, so add the wayland-client dependency. This fixes those tests if e.g. wayland-client headers need to be found through pkgconfig. This part of the code changed completely in Qt 6, so this is a totally different patch and not a cherry-pick of 5fc2e1915c3a ("CMake: Fix qtwayland feature detection"). |
Fabian Vogt <fabian@ritter-vogt.de> | no | 2022-02-04 | ||
| 0035-client-update-button-state-and-etc-in-pointer_leave.patch | [PATCH] client: update button state and etc in pointer_leave() The cleanup work needs to be done even the surface is null, for example, a window was closed in mouse press handler, then will not get a mouse release. (cherry picked from commit 409d1080f25b653b3ff3f57c9776c5c390912206) |
Liang Qi <liang.qi@qt.io> | no | 2022-03-09 | ||
| 0036-Revert-Client-Remove-mWaitingForUpdateDelivery.patch | [PATCH] Revert "Client: Remove mWaitingForUpdateDelivery" The reverted commit introduces a severe performance regression when a client window is resized while a QtQuick renderthread animation is running. This reverts commit feb1a5c207c13d0bf87c0d8ad039279dbf8cee9e. |
Paul Olav Tvete <paul.tvete@qt.io> | no | 2022-03-15 | ||
| 0037-Fix-race-condition-on-mWaitingForUpdateDelivery.patch | [PATCH] Fix race condition on mWaitingForUpdateDelivery | Paul Olav Tvete <paul.tvete@qt.io> | no | 2022-03-15 | ||
| 0038-use-poll-2-when-reading-from-clipboard.patch | [PATCH] use poll(2) when reading from clipboard change clipboard read away from select(2) call which can fail when an application has large number of open files (cherry picked from commit 829a9f62a96721c142f53e12a8812e8231b20317) |
Kenneth Topp <ken@bllue.org> | no | 2022-04-04 | ||
| 0039-Reduce-memory-leakage.patch | [PATCH] Reduce memory leakage We need to clean up the event queue when we're done. (cherry picked from commit 1264e5f565d8fb7ac200e4b00531ab876922458f) |
Ulf Hermann <ulf.hermann@qt.io> | no | 2022-02-22 | ||
| 0040-Fix-build-with-libcxx-missing-array-include.patch | [PATCH] Fix build with libcxx (missing array include) (cherry picked from commit 5065013b0c2346b5918a2681ae2e58046140e8a7) |
Sam James <sam@gentoo.org> | yes | upstream | 2022-06-18 | |
| 0041-Only-close-popup-in-the-the-hierchary.patch | [PATCH] Only close popup in the the hierchary Imagine following event sequences: 1. a tooltip is shown. activePopups = {tooltip} 2. user click menu bar to show the menu, QMenu::setVisible is called. now activePopups(tooltip, menu} 3. tooltip visibility changed to false. 4. closePopups() close both tooltip and menu. This is a common pattern under wayland that menu is shown as a invisible state. This patch tries to memorize the surface hierchary used to create the popup role. And only close those popups whose ancesotor is hidden. (cherry picked from commit f8e3257e9b1e22d52e9c221c62b8d9b6dd1151a3) |
Weng Xuetian <wengxt@gmail.com> | no | 2022-07-20 | ||
| 0042-Build-fixes-for-GCC-11.patch | [PATCH] Build fixes for GCC 11 (cherry picked from commit 1aa6ec2c778504d96543f6cdc2b9199a7b066fc1) |
Ville Voutilainen <ville.voutilainen@qt.io> | no | 2021-01-18 | ||
| 0043-Check-pointer-for-null-before-use-in-ASSERT.patch | [PATCH] Check pointer for null before use in ASSERT (cherry picked from commit e235e8ddb1fc3cc5ab3b70b1fb285770b2c8c9ca) |
Roman Genkhel <roman.genhel@lge.com> | no | 2020-11-12 | ||
| 0044-Use-wl_surface.damage_buffer-on-the-client-side.patch | [PATCH] Use wl_surface.damage_buffer on the client side Prefer the newer, recommended damage_buffer when the compositor supports it. (cherry picked from commit 314fd6db51277224cdc799b039ef79db1101f5cd) |
Paul Olav Tvete <paul.tvete@qt.io> | no | 2020-07-06 | ||
| 0045-Client-clear-focus-on-touch-cancel.patch | [PATCH] Client: clear focus on touch cancel When we get a touch_cancel event all touches should be treated as lifted. The next frame call focus is set, with no pending touch points but without having gone through touch_up. We call mPendingTouchPoints.last() without guards even though it is potentially now empty. (cherry picked from commit dbdcd92363b44d89440dcb195d8cb9e6c34f0ddf) |
David Edmundson <davidedmundson@kde.org> | no | 2022-08-05 | ||
| 0046-Guard-mResizeDirty-by-the-correctMutex.patch | [PATCH] Guard mResizeDirty by the correctMutex mResizeDirty is used in the GUI thread in setCanResize which can be called from the GUI thread. It is queried and set whilst the resizeLock is held. We need to guard our usage. (cherry picked from commit 4ac96662c936821efff2875bbe555b40612caf8a) |
David Edmundson <davidedmundson@kde.org> | no | 2022-02-03 | ||
| 0047-client-Synthesize-enter-leave-event-for-popup-in-xdg.patch | [PATCH] client: Synthesize enter/leave event for popup in xdg-shell (cherry picked from commit 73d35d3117722cef8e94f0d2036c56ad0a5ddae9) * asturmlechner 2022-09-08: Resolve conflict with dev branch commits b6a3a938abd4a7fdb7ea96a38485b53f394fba17 and f8e3257e9b1e22d52e9c221c62b8d9b6dd1151a3 |
Liang Qi <liang.qi@qt.io> | no | 2022-03-11 | ||
| 0048-Fix-compile-tests.patch | [PATCH] Fix compile tests Broken in c618467da4c06528537026e2b78f92265bce446f |
Albert Astals Cid <aacid@kde.org> | no | 2022-09-09 | ||
| 0049-Use-CRLF-line-delimiter-for-text-uri-list-data.patch | [PATCH] Use CRLF line delimiter for text/uri-list data According to RFC 2483, which describes text/uri-list, the line delimiter must be CRLF (instead of the currently used LF). Some applications strictly expect the CRLF delimiter and fail to properly parse the uri-list otherwise (e.g., WineX11/XWayland). https://datatracker.ietf.org/doc/html/rfc2483 5. The text/uri-list Internet Media Type The format of text/uri-list resources is: 3) As for all text/* formats, lines are terminated with a CRLF pair. (cherry picked from commit bd5b0a804b91b9fbd0ce44d5d6765e07d0a50b4f) |
Alexandros Frantzis <alexandros.frantzis@collabora.com> | no | 2022-05-11 | ||
| 0050-Fix-missing-update-when-toggling-client-side-decorat.patch | [PATCH] Fix missing update when toggling client-side decorations When CSD is toggled while a window is showing, it would change the size and recreate the buffers, but since the widget area remained the same size, we would not trigger a redraw. The result was that when you got any update to the window, it would redraw the widgets that had changed, and the rest would be transparent. Since this is a fairly specialized case, we fix it the simple way, by just issuing an extra update when it happens. This also required an update to the surface test, since there is an additional buffer commit in the beginning of the sequence now. (cherry picked from commit af7b60ade5c4be81cbc58eb18307c017d5594071) |
Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io> | no | 2021-11-09 | ||
| 0051-Avoid-calling-requestUpdate-from-wrong-thread.patch | [PATCH] Avoid calling requestUpdate from wrong thread In certain circumstances, we can get to createDecoration() from the render thread (from QWaylandGLContext::makeCurrent) Calling requestUpdate() from this secondary thread would cause an assert, so we queue the call on the appropriate thread instead. This amends af7b60ade5c4be81cbc58eb18307c017d5594071. (cherry picked from commit a0c0b5b42335808c2222cbf72c1758e955731ed9) |
Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io> | no | 2022-08-08 | ||
| 0052-Client-support-high-dpi-mode-for-window-icon.patch | [PATCH] Client: support high-dpi mode for window icon (cherry picked from commit fc91cd6b1306c6d452cbddab3c2289ccb92218d6) |
Liang Qi <liang.qi@qt.io> | no | 2021-12-13 | ||
| 0053-Call-finishDrag-in-QWaylandDataDevice-dragSourceCanc.patch | [PATCH] Call `finishDrag()` in `QWaylandDataDevice::dragSourceCancelled()` Drags can either get finished or cancelled. If a drag is finished successfully we call finish on the QBasicDrag instance, which quits the nested event loop. This patch adds the connection for cancelled drags. See also: https://bugs.kde.org/show_bug.cgi?id=446111 (cherry picked from commit c92282b865efcf8c571bb52b5f96d8ad260a1cda) |
Fushan Wen <qydwhotmail@gmail.com> | no | upstream | 2022-09-18 | |
| 0054-Hold-surface-read-lock-throughout-QWaylandEglWindow-.patch | [PATCH] Hold surface read lock throughout QWaylandEglWindow::updateSurface QWaylandEGLWindow::updateSurface is called from both the main and render threads. It is called on the render thread when making the surface current, which could be after the window is hidden if there are cleanup jobs to be done. Whilst the getter wlSurface() holds a read lock, it's not enough as we need the instance alive between the two calls and throughout the mesa code. This potentially fixes a crash seen in mesa where we crash creating a surface for an invalid wl_surface object. (cherry picked from commit 50f1ccc66c68f9f4c0b08400747942109c16b2be) |
David Edmundson <davidedmundson@kde.org> | no | 2022-09-12 | ||
| 0055-Client-Ensure-that-wl_surface-lives-as-long-as-qtqui.patch | [PATCH] Client: Ensure that wl_surface lives as long as qtquick render thread needs it wl_surface can be destroyed while qtquick render thread still uses it. That can end up in eglSwapBuffers() using defunct wl_surface, which will eventually lead to a crash due to the compositor posting an error. This is partially cherry-pick of dff579147b07cd15888a47c303e36684e9930f9f |
Vlad Zahorodnii <vlad.zahorodnii@kde.org> | no | 2022-11-08 | ||
| 0056-Keep-toplevel-windows-in-the-top-left-corner-of-the-.patch | [PATCH] Keep toplevel windows in the top left corner of the screen We can't know the actual position of a window on the screen. This causes an issue when Widgets try to position a popup/menu absolutely and keep it on the screen when the screen geometry doesn't include (0,0). Instead report their positions always as the top left corner of the screen that they are on. This new behavior can be disabled for qt-shell or via an environment variable by users that rely on the old behavior. (cherry picked from commit a46795a22e05722917c6ebc60ed01bebf49898ae) |
David Redondo <qt@david-redondo.de> | no | 2022-06-08 | ||
| 0057-Revert-Client-Ensure-that-wl_surface-lives-as-long-a.patch | [PATCH] Revert "Client: Ensure that wl_surface lives as long as qtquick render thread needs it" This reverts commit 81a7702a87f386a60a0ac8c902e203daae044d81 |
David Edmundson <kde@davidedmundson.co.uk> | no | 2022-11-14 | ||
| 0058-Client-Add-F_SEAL_SHRINK-seal-to-shm-backing-file.patch | [PATCH] Client: Add F_SEAL_SHRINK seal to shm backing file This lets libwayland-server avoid installing a SIGBUS handler when it wants to mmap() the backing file and access the contents of shared memory client buffers. (cherry picked from commit 0c1cbb376e0cf878e3a91ab4917fe784a3b4c547) |
Vlad Zahorodnii <vlad.zahorodnii@kde.org> | no | 2022-11-17 | ||
| 0059-Client-Call-wl_output_release-upon-QWaylandScreen-de.patch | [PATCH] Client: Call wl_output_release() upon QWaylandScreen destruction It ensures that the proxy gets destroyed. (cherry picked from commit 054e54759dbd6c3e76b55d5c4a9a54f62967ad1a) |
Vlad Zahorodnii <vlad.zahorodnii@kde.org> | no | 2022-11-21 | ||
| 0060-Client-Bump-wl_output-version.patch | [PATCH] Client: Bump wl_output version wl_output_release is available starting with wl_output v3. (cherry picked from commit c14916f5fd84f6b5483024b3df77592661a0f04e) |
Vlad Zahorodnii <vlad.zahorodnii@kde.org> | no | 2022-11-22 | ||
| 0061-Fix-frame-sync-related-to-unprotected-multithread-ac.patch | [PATCH] Fix frame sync related to unprotected multithread access There is a few crashes happens in real life that frame callback is double-free'd and hit an assertion in wayland-client. e.g. https://bugs.kde.org/show_bug.cgi?id=450003 This is due to the WaylandEventThread and calls to QWaylandWindow::reset may free and unset the mFrameCallback at the same time. mFrameSyncMutex should be used to protect such access. (cherry picked from commit b6cbb5e323822d6e3ef5ed4dd5a4c4cc1ea85038) |
Weng Xuetian <wengxt@gmail.com> | no | 2022-11-27 | ||
| 0062-Client-Handle-zwp_primary_selection_device_manager_v.patch | [PATCH] Client: Handle zwp_primary_selection_device_manager_v1 global removal The zwp_primary_selection_device_manager_v1 global can be withdrawn if the compositor disables the primary selection, i.e. middle click to paste selected text. QtWayland needs to handle that; otherwise the app can crash. (cherry picked from commit 45163234a4e4baad0012d3ee07501093d98ba91c) |
Vlad Zahorodnii <vlad.zahorodnii@kde.org> | no | 2022-09-27 | ||
| 0063-Fixes-the-build-on-CentOS.patch | [PATCH] Fixes the build on CentOS | Aleix Pol <aleixpol@kde.org> | no | 2022-12-19 | ||
| 0064-client-Avoid-protocol-error-with-invalid-min-max-siz.patch | [PATCH] client: Avoid protocol error with invalid min/max size If the application sets an invalid minimum and maximum size (where the minimum is higher than the maximum), then we would blindly send this over the protocol, which is a protocol error according to the spec. Qt compositors will warn about this and ignore the size, but mainly because "but there's no matching error defined" according to the comment. Other compositors may close the connection when this happens. To avoid crashing the app based on bogus min/max size, we make sure we never send a maximum size which is less than the minimum size. This corresponds to the behavior of compositors which accept the size without raising an error: the minimum size takes precedence. Note that 0 means "no maximum size" in the protocol, so we cap the value before applying this logic. [ChangeLog][Client] Fixed an issue where setting an invalid minimum and maximum size on a window would cause some compositors to raise a protocol error. (cherry picked from commit 487de47277ccc31891f6340ce4c971c91336d9a4) |
Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io> | no | 2022-05-23 |