Details
-
Bug
-
Resolution: Done
-
P1: Critical
-
5.12.12
-
None
-
5463a04097ee7824b2032fb058e289cf62bfd315 (qt/qtwayland/dev) 2dcd37cbb893aac874ee090e5f6e2c1d1f1e3039 (qt/qtwayland/5.12) 168fb4df66b64e5f3d43b548c869b7c8a31000f3 (qt/qtwayland/6.2) 41f8aa24d30a896d69e7ddeced61911d785518e9 (qt/tqtc-qtwayland/5.15)
Description
We have been developing HMI application, it's implementation of
Wayland compositor based on QtWayland module. One of our Wayland client has
faced with problem. This client is GStreamer pipeline. The step of this pipeline respnonded to wayland communication is released by Gstwaylandsink. From client point of view the problem that wl_buffer isn't released by compositor application.
From client side we have the following request:
" From the view of log hmi_test.txt, Gstwaylandsink attachs the wl_buffer@18 in line 4926. But wl_buffer@18 was not released by QT compositor. The same with other wayland buffers. Therefore, the video decoder starves for buffer, which leads to video freeze. The video frozen issue happens only - when switch between pages. If no switching happened, video decoding works well. Therefore, I think it’s not a issue of GStreamer side. We suspect QT compositor didn’t post release event to Gstwaylandsink leading to the issue, the question is why QT compositor is not releasing the buffers. "
Explanations: Compositor application has QML context. Pages - some QML content
which dynamically loaded by Loader component. One of the pages contains a
container for QWaylandSurface. The problem happens when pages with client
content are reloaded by QML engine.
Our application doesn't use specific Wayland commands, all communication with
client side is processed by Qt interfaces. So, currently it seems that problem
can be related to internal behavior of QtWayland module.
Attachments
Issue Links
- is duplicated by
-
QTBUG-94599 Releasing wayland buffer from Qt compositor side
- Closed