Source: kwayland
Version: 5.12.1-1
Severity: important
Dear Maintainer,
zwp_linux_dmabuf protocol support is needed to properly work with the drm
backend to display Plasma Mobile on the Librem 5 development board.
The implementation of zwp_linux_dmabuf support is being tracked by KDE in
https://phabricator.kde.org/D10747
Also see relating email thread for complete details:
https://www.mail-archive.com/plasma-devel@kde.org/msg81108.html
The proposed patches attached to D10747 (and this bug report) do indeed
fix the display issue.
Please consider carrying the kwin patch ahead of the Plasma 5.13 release
(scheduled for June 2018).
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: armhf (armv7l)
Kernel: Linux 4.15.0-g837bff1 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot
set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968), LANGUAGE=en_US.UTF-8 (charmap=locale: Cannot set
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/src/client/protocols/linux-dmabuf-unstable-v1.xml b/src/client/protocols/linux-dmabuf-unstable-v1.xml
new file mode 100644
--- /dev/null
+++ b/src/client/protocols/linux-dmabuf-unstable-v1.xml
@@ -0,0 +1,348 @@
+
+
+
+
+Copyright © 2014, 2015 Collabora, Ltd.
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+
+
+
+
+ Following the interfaces from:
+ https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
+ and the Linux DRM sub-system's AddFb2 ioctl.
+
+ This interface offers ways to create generic dmabuf-based
+ wl_buffers. Immediately after a client binds to this interface,
+ the set of supported formats and format modifiers is sent with
+ 'format' and 'modifier' events.
+
+ The following are required from clients:
+
+ - Clients must ensure that either all data in the dma-buf is
+coherent for all subsequent read access or that coherency is
+correctly handled by the underlying kernel-side dma-buf
+implementation.
+
+ - Don't make any more attachments after sending the buffer to the
+compositor. Making more attachments later increases the risk of
+the compositor not being able to use (re-import) an existing
+dmabuf-based wl_buffer.
+
+ The underlying graphics stack must ensure the following:
+
+ - The dmabuf file descriptors relayed to the server will stay valid
+for the whole lifetime of the wl_buffer. This means the server may
+at any time use those fds to import the dmabuf into any kernel
+sub-system that might accept it.
+
+ To create a wl_buffer from one or more dmabufs, a client creates a
+ zwp_linux_dmabuf_params_v1 object with a zwp_linux_dmabuf_v1.create_params
+ request. All planes required by the intended format are added with
+ the 'add' request. Finally, a 'create' or 'create_immed' request is
+ issued, which has the following outcome depending on the import success.
+
+ The 'create' request,
+ - on success, triggers a 'created' event which provides the final
+wl_buffer to the client.
+ - on failure, triggers a 'failed' event to convey that the server
+cannot use the dmabufs received from the client.
+
+ For the 'create_immed' request,
+ - on success, the server immediately imports the added dmabufs to
+create a wl_buffer. No event is
