Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
---|---|---|---|---|---|---|
wayland_1.23.diff | update wayland.xml to version 1.23.0 This updates only the protocol definition, implementations will need additional commits to opt into using them. |
no | upstream, https://code.qt.io/cgit/qt/qtwayland.git/commit/?id=c2f61bc47baacf2e | 2024-07-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 | ||
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 | ||
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 | ||
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 | ||
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 | ||
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 | ||
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 | ||
0048-Fix-compile-tests.patch | [PATCH] Fix compile tests Broken in c618467da4c06528537026e2b78f92265bce446f |
Albert Astals Cid <aacid@kde.org> | no | 2022-09-09 | ||
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 | ||
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 | ||
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 | ||
0065-Client-Fix-handling-of-Qt-BlankCursor.patch | [PATCH] Client: Fix handling of Qt::BlankCursor The cursor may not be properly set when a window has Qt::BlankCursor and it's shown. In that case, the cursor surface may not be present and wl_pointer.set_cursor won't be called. On the other hand, wl_pointer.set_cursor must be always called when wl_pointer.enter is received. (cherry picked from commit e954853f0e68d78ac1a98bc3533713881496064c) |
Vlad Zahorodnii <vlad.zahorodnii@kde.org> | no | 2022-11-22 | ||
0066-client-Force-a-roundtrip-when-an-XdgOutput-is-not-re.patch | [PATCH] client: Force a roundtrip when an XdgOutput is not ready yet Is possible that the server sends a surface_enter before all the information of the XdgOutput have been processed by the client. in this case the associated QScreen doesn't exist yet, causing a QWindow::SetScreen(nullptr), which will fall back to QGuiApplication::primaryScreen(), having the QWindow being assigned the wrong screen |
Marco Martin <notmart@gmail.com> | no | 2023-02-24 | ||
0070-Destroy-frame-queue-before-display.patch | [PATCH] Destroy frame queue before display wl_event_queue_destroy accesses the display. Found by running a test under valgrind. (cherry picked from commit a76bf824fcd1cc3789f0d3454a0423c0241d9718) |
David Redondo <qt@david-redondo.de> | no | 2023-04-11 | ||
0071-client-Fix-crash-on-dnd-updates-after-client-facing-.patch | [PATCH] client: Fix crash on dnd updates after client facing drag ends A platform drag and a application-facing drag have two different lifespans. The platform drag lasts until all mimedata is transferred and the client receiving the drops marks it as finished. The application facing QDrag lasts until the client deletes it. We can get a crash if we get updates during this time. The drop event is guarded, but not the action negotiation. (cherry picked from commit 22daca49b807fefba58113a06b86df4274e49f62) |
David Edmundson <davidedmundson@kde.org> | no | 2023-06-07 | ||
0072-Convert-cursor-bitmap-to-supported-format.patch | [PATCH] Convert cursor bitmap to supported format The 1-bit image formats QImage::Format_Mono and QImage::Format_MonoLSB used by cursor bitmaps don't have a corresponding wl_shm_format. Therefore, convert to a supported image format as necessary to make such bitmap cursors work on Wayland as well. (cherry picked from commit 45ec1362f8fcb5ade92f4d2d4985b1c24e78c8ba) Backport changes: Use Qt::ReturnByValue version for QCursor::mask() and QCursor::bitmap() |
Michael Weghorn <m.weghorn@posteo.de> | no | 2023-02-20 | ||
0073-Replace-scale-with-devicePixelRatio-for-non-integer-.patch | [PATCH] Replace scale with devicePixelRatio for non-integer scaling The 'scale' event from wayland cannot support non-integer scaling which was originally supported in Qt. As default, devicePixelRatio follows the 'scale' so that the high DPI still works as the mechanism in Wayland. But if non-integer scaling factor such as 150% is needed, it can be supported to override the devicePixelRatio. (cherry picked from commit cf98abbc6ae9ba9373803ffe193f839324e0c80b) |
Jungi Byun <jungi.byun@lge.com> | no | 2021-01-27 | ||
0074-Client-Fix-buffer-damage.patch | [PATCH] Client: Fix buffer damage If the specified damage rectangle has fractional coordinates in the buffer local coordinate space, the buffer damage needs to be expanded, i.e. - bufferRect.left = floor(rect.left * scale) - bufferRect.right = ceil(rect.right * scale) = ceil((rect.x + rect.width) * scale) Flooring the coordinates and ceiling the size is not enough. It can produce incorrect results. For example, consider that a rectangle with logical coordinates of QRect(0, 23, 179, 46) has been damaged in a window with scale 1.5. When flooring the coordinates and ceiling the size, the following buffer damage rect will be produced: QRect(0, 34, 269, 69). Its height is off by 1, the expected height is 70 (ceil((23 + 46) * 1.5) - floor(23 * 1.5) = ceil(103.5) - floor(34.5) = 104 - 34 = 70). (cherry picked from commit d79db699866b37bd3e3358ca18a210dfc5c0b4b9) |
Vlad Zahorodnii <vlad.zahorodnii@kde.org> | no | 2023-08-03 | ||
0077-Client-Commit-the-initial-surface-state-explicitly.patch | [PATCH] Client: Commit the initial surface state explicitly QWaylandWindow lacks an explicit step to finish initializing the shell surface by committing the surface. So far it used to work because of hidden surface commits in QWaylandWindow::handleContentOrientationChange(), QWaylandWindow::setMask() and so on. This change adds an explicit step to commit the initial surface state to make the shell surface initialization robust. (cherry picked from commit 225432c2294bdfbf24856b2f155cd274b24543b2) |
Vlad Zahorodnii <vlad.zahorodnii@kde.org> | no | 2023-08-25 | ||
0078-tests-Fix-tst_xdgshell-minMaxSize.patch | [PATCH] tests: Fix tst_xdgshell::minMaxSize() Amends e8cff6fb39c0fd01548bce18542820a6612dbe49. The new size hints will be committed when the surface is committed. (cherry picked from commit d8d3d6097afeac62f1b0285e3d5365c7cb580547) |
Vlad Zahorodnii <vlad.zahorodnii@kde.org> | no | 2023-09-15 | ||
0080-Client-Avoid-locking-resizing-in-QWaylandShmBackingS.patch | [PATCH] Client: Avoid locking resizing in QWaylandShmBackingStore QWaylandWindow::setCanResize(false) will block applying configure events. QWaylandWindow::setCanResize(true) will unblock configure events and potentially apply a scheduled configure event if there's one. QWaylandWindow::setCanResize(true) has to be called **after** committing the surface to ensure that the xdg window geometry matches the buffer. We don't want the xdg window geometry change when painting. Unfortunately, setCanResize(true) can be called before the surface is committed when using a RasterSurface, for example - QWaylandShmBackingStore::beginPaint(): calls setCanResize(false) - QWaylandShmBackingStore::endPaint(): calls setCanResize(true) - QWaylandWindow::setCanResize(true): applies pending configure event - QWaylandShmBackingStore::flush(): commits the surface, but the xdg window geometry is wrong now As is, beginPaint() and endPaint() are not entirely correct functions where configure events can be blocked. We need functions that wrap both painting and flushing, which are not feasible with the current backing store design. On the other hand, it's worth noting that blocking configure events in the backing store is not necessary because painting happens on the main thread unlike OpenGL or Vulkan code paths. Given the lack of synchronization points and the fact that rendering happens on the main thread, this change removes blocking configure events in QWaylandShmBackingStore. It fixes dolphin and various other applications that use QtWidgets jumping while being interactively resized. (cherry picked from commit 8828452bcf2ecf4e02a64380a1697d148c4366b0) |
Vlad Zahorodnii <vlad.zahorodnii@kde.org> | no | 2023-08-30 | ||
0081-Client-Always-populate-mimedata-in-drags.patch | [PATCH] Client: Always populate mimedata in drags It's possible for clients to perform a drag and drop operation within their own client without any mimeData. A user can directly access the original drag. On wayland without any mimedata it's impossible for a client to accept a drag as the mechansim involved is to either select a given mimedata entry or an empty string. Within Qt we always accept the first format if we accept a drag. When dragging within our own window we also start a wayland drag so will receive a cancel event from the compositor if the compositor doesn't believe the client has accepted the drag. This patch provides a dummy mimedata entry so that something can be accepted. (cherry picked from commit 32fedb6fa6579711b6cb192a2e3cfb7ad1264546) * asturmlechner 2023-10-24: Backported L1 literal as QString::fromLatin1 |
David Edmundson <davidedmundson@kde.org> | no | 2023-05-17 | ||
0082-Client-Fix-enter-event-cursor-position-with-xdg-popu.patch | [PATCH] Client: Fix enter event cursor position with xdg-popup and QHighDpiScaling QWindowSystemInterface::handleEnterEvent accepts device-dependent position while QCursor::pos provides device-independent position. Use QWaylandCursor::pos instead. (cherry picked from commit 8e57e8b51b2b701c5520f37b7d78de5b3c488500) |
Ilya Fedin <fedin-ilja2010@ya.ru> | no | 2023-12-03 | ||
0083-client-don-t-cache-one-type-in-QWaylandMimeData.patch | [PATCH] client: don't cache one type in QWaylandMimeData "application/vnd.portal.filetransfer", which is only valid for one time use. (cherry picked from commit 19758eb4093e8d60c69f75174afb7457490e2332) |
Liang Qi <liang.qi@qt.io> | no | 2024-03-13 | ||
0084-Fix-race-condition-in-drag-and-drop.patch | [PATCH] Fix race condition in drag and drop The data source may be deleted by libwayland while we hold a reference to it. This could cause crashes when dragging and dropping repeatedly and very rapidly between two components. Tapping into sourceDestroyed() for this as well allows us to recover more gracefully. This also required adding some null pointer checks to the code, since it wasn't really prepared for the data source disappearing. (cherry picked from commit 792bd8510e3bc6b47bcaedfb1386390ce3a10a3a) |
Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io> | no | 2024-05-10 | ||
0085-Revert-Client-Send-release-button-event-on-pointer-l.patch | [PATCH] Revert "Client: Send release button event on pointer leave" This reverts commit 8235fa65fe033a94e7a44322d3502f25940092ec. It makes tests/manual/examples/widgets/draganddrop/puzzle not work, which does drag and drop in same app. (cherry picked from commit 60647fa069ef4143642ae4c1b529ad2a7a7f2fd9) |
Liang Qi <liang.qi@qt.io> | no | 2023-09-06 | ||
skip_animated_cursor_test.diff | skip tst_seatv4::animatedCursor that fails in Debian | Dmitry Shachnev <mitya57@debian.org> | not-needed | upstream | 2020-04-30 |