Script 'mail_helper' called by obssrc
Hello community,
here is the log from the commit of package wayland-protocols for
openSUSE:Factory checked in at 2021-11-27 00:50:38
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/wayland-protocols (Old)
and /work/SRC/openSUSE:Factory/.wayland-protocols.new.1895 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "wayland-protocols"
Sat Nov 27 00:50:38 2021 rev:26 rq:933409 version:1.24
Changes:
--------
--- /work/SRC/openSUSE:Factory/wayland-protocols/wayland-protocols.changes
2021-11-13 22:48:14.337236751 +0100
+++
/work/SRC/openSUSE:Factory/.wayland-protocols.new.1895/wayland-protocols.changes
2021-11-27 00:51:19.514801885 +0100
@@ -1,0 +2,12 @@
+Wed Nov 24 08:29:20 UTC 2021 - Christophe Giboudeaux <christo...@krop.fr>
+
+- Update to 1.24
+ * This release adds feedback to the DMA buffer protocol
+ * tests: allow cross-compiling the tests
+ * tests: check whether -Wl,--unresolved-symbols=ignore-all is
+ supported
+ * meson.build: wayland-scanner is only needed for tests
+ * Improve tiled_* enum summary
+- Rebase
wayland-protocols-disable-pedantic-test-unstable-xdg-decoration-on-ppc64.patch
+
+-------------------------------------------------------------------
Old:
----
wayland-protocols-1.23.tar.xz
wayland-protocols-1.23.tar.xz.sig
New:
----
wayland-protocols-1.24.tar.xz
wayland-protocols-1.24.tar.xz.sig
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ wayland-protocols.spec ++++++
--- /var/tmp/diff_new_pack.cEXE3e/_old 2021-11-27 00:51:20.074799952 +0100
+++ /var/tmp/diff_new_pack.cEXE3e/_new 2021-11-27 00:51:20.078799938 +0100
@@ -18,7 +18,7 @@
Name: wayland-protocols
-Version: 1.23
+Version: 1.24
Release: 0
Summary: Wayland protocols that add functionality not available in the
core protocol
License: MIT
++++++ wayland-protocols-1.23.tar.xz -> wayland-protocols-1.24.tar.xz ++++++
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.23/.gitlab-ci.yml
new/wayland-protocols-1.24/.gitlab-ci.yml
--- old/wayland-protocols-1.23/.gitlab-ci.yml 2021-09-15 14:52:03.135998200
+0200
+++ new/wayland-protocols-1.24/.gitlab-ci.yml 2021-11-23 10:13:33.065573500
+0100
@@ -19,8 +19,8 @@
.debian:
variables:
FDO_DISTRIBUTION_VERSION: bullseye
- FDO_DISTRIBUTION_PACKAGES: 'build-essential automake autoconf libtool
pkg-config libwayland-dev meson'
- FDO_DISTRIBUTION_TAG: '2021-03-24.0'
+ FDO_DISTRIBUTION_PACKAGES: 'build-essential pkg-config libwayland-dev
meson'
+ FDO_DISTRIBUTION_TAG: '2021-11-09.0'
check-commit:
extends:
@@ -52,12 +52,3 @@
- ninja -C build
- meson test -C build
- ninja -C build install
-
-test-autotools:
- stage: test
- extends:
- - .debian
- - .fdo.distribution-image@debian
- script:
- - ./autogen.sh
- - make check
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.23/Makefile.am
new/wayland-protocols-1.24/Makefile.am
--- old/wayland-protocols-1.23/Makefile.am 2021-09-15 14:52:03.136998200
+0200
+++ new/wayland-protocols-1.24/Makefile.am 1970-01-01 01:00:00.000000000
+0100
@@ -1,73 +0,0 @@
-ACLOCAL_AMFLAGS = -I m4
-
-unstable_protocols =
\
- unstable/pointer-gestures/pointer-gestures-unstable-v1.xml
\
- unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
\
- unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
\
- unstable/text-input/text-input-unstable-v1.xml
\
- unstable/text-input/text-input-unstable-v3.xml
\
- unstable/input-method/input-method-unstable-v1.xml
\
- unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
- unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
- unstable/relative-pointer/relative-pointer-unstable-v1.xml
\
- unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
\
- unstable/tablet/tablet-unstable-v1.xml
\
- unstable/tablet/tablet-unstable-v2.xml
\
- unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
\
- unstable/xdg-foreign/xdg-foreign-unstable-v2.xml
\
- unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
\
- unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
\
-
unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
- unstable/xdg-output/xdg-output-unstable-v1.xml
\
- unstable/input-timestamps/input-timestamps-unstable-v1.xml \
- unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \
-
unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
\
- unstable/primary-selection/primary-selection-unstable-v1.xml
\
- $(NULL)
-
-stable_protocols =
\
- stable/presentation-time/presentation-time.xml
\
- stable/viewporter/viewporter.xml
\
- stable/xdg-shell/xdg-shell.xml
\
- $(NULL)
-
-staging_protocols =
\
- staging/drm-lease/drm-lease-v1.xml
\
- staging/xdg-activation/xdg-activation-v1.xml
\
- $(NULL)
-
-misc_documentation =
\
- staging/xdg-activation/x11-interoperation.rst
\
- $(NULL)
-
-nobase_dist_pkgdata_DATA =
\
- $(unstable_protocols)
\
- $(stable_protocols)
\
- $(staging_protocols)
\
- $(NULL)
-
-dist_noinst_DATA =
\
- $(sort $(foreach p,$(unstable_protocols),$(dir $p)README))
\
- $(sort $(foreach p,$(stable_protocols),$(dir $p)README))
\
- $(sort $(foreach p,$(staging_protocols),$(dir $p)README))
\
- $(misc_documentation)
\
- README.md
\
- GOVERNANCE.md
\
- MEMBERS.md
\
- meson.build
\
- meson_options.txt
\
- tests/meson.build
\
- tests/build-cxx.cc.in
\
- tests/build-pedantic.c.in
\
- tests/replace.py
\
- tests/scan.sh
\
- $(NULL)
-
-noarch_pkgconfig_DATA = wayland-protocols.pc
-
-dist_check_SCRIPTS = tests/scan.sh
-
-TESTS = $(unstable_protocols) $(stable_protocols) $(staging_protocols)
-TEST_EXTENSIONS = .xml
-AM_TESTS_ENVIRONMENT = SCANNER='$(wayland_scanner)'; export SCANNER;
-XML_LOG_COMPILER = $(srcdir)/tests/scan.sh
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.23/autogen.sh
new/wayland-protocols-1.24/autogen.sh
--- old/wayland-protocols-1.23/autogen.sh 2021-09-15 14:52:03.136998200
+0200
+++ new/wayland-protocols-1.24/autogen.sh 1970-01-01 01:00:00.000000000
+0100
@@ -1,9 +0,0 @@
-#!/bin/sh
-
-test -n "$srcdir" || srcdir=`dirname "$0"`
-test -n "$srcdir" || srcdir=.
-(
- cd "$srcdir" &&
- autoreconf --force -v --install
-) || exit
-test -n "$NOCONFIGURE" || "$srcdir/configure" "$@"
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.23/configure.ac
new/wayland-protocols-1.24/configure.ac
--- old/wayland-protocols-1.23/configure.ac 2021-09-15 14:52:03.136998200
+0200
+++ new/wayland-protocols-1.24/configure.ac 1970-01-01 01:00:00.000000000
+0100
@@ -1,45 +0,0 @@
-AC_PREREQ([2.64])
-
-m4_define([wayland_protocols_major_version], [1])
-m4_define([wayland_protocols_minor_version], [23])
-m4_define([wayland_protocols_version],
- [wayland_protocols_major_version.wayland_protocols_minor_version])
-
-AC_INIT([wayland-protocols],
- [wayland_protocols_version],
-
[https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=wayland&version=unspecified],
- [wayland-protocols],
- [http://wayland.freedesktop.org/])
-
-AC_CONFIG_MACRO_DIR([m4])
-
-AC_SUBST([WAYLAND_PROTOCOLS_VERSION], [wayland_protocols_version])
-
-AC_ARG_VAR([wayland_scanner], [The wayland-scanner executable])
-AC_PATH_PROG([wayland_scanner], [wayland-scanner])
-if test x$wayland_scanner = x; then
- if test "x$cross_compiling" != "xyes"; then
- PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner])
- wayland_scanner=`$PKG_CONFIG --variable=wayland_scanner
wayland-scanner`
- else
- AC_MSG_WARN([You are cross compiling without wayland-scanner
in your path. make check will fail.])
- fi
-fi
-
-AM_INIT_AUTOMAKE([1.11 foreign no-dist-gzip dist-xz tar-ustar])
-
-AM_SILENT_RULES([yes])
-
-PKG_NOARCH_INSTALLDIR
-
-AC_CONFIG_FILES([
- Makefile
- wayland-protocols.pc
- wayland-protocols-uninstalled.pc
- ])
-AC_OUTPUT
-
-AC_MSG_RESULT([
- Version ${WAYLAND_PROTOCOLS_VERSION}
- Prefix ${prefix}
- ])
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.23/m4/compat.m4
new/wayland-protocols-1.24/m4/compat.m4
--- old/wayland-protocols-1.23/m4/compat.m4 2021-09-15 14:52:03.136998200
+0200
+++ new/wayland-protocols-1.24/m4/compat.m4 1970-01-01 01:00:00.000000000
+0100
@@ -1,12 +0,0 @@
-dnl noarch_pkgconfigdir only available in pkg-config 0.27 and newer
-dnl http://lists.freedesktop.org/archives/pkg-config/2012-July/000875.html
-dnl Ubuntu 14.04 provides only pkg-config 0.26 so lacks this function.
-dnl
-dnl The Wayland project maintains automated builds for Ubuntu 14.04 in
-dnl a Launchpad PPA. 14.04 is a Long Term Support distro release, which
-dnl will reach EOL April 2019, however the Wayland PPA may stop targeting
-dnl it some time after the next LTS release (April 2016).
-m4_ifndef([PKG_NOARCH_INSTALLDIR], [AC_DEFUN([PKG_NOARCH_INSTALLDIR], [
- noarch_pkgconfigdir='${datadir}'/pkgconfig
- AC_SUBST([noarch_pkgconfigdir])
-])])
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.23/meson.build
new/wayland-protocols-1.24/meson.build
--- old/wayland-protocols-1.23/meson.build 2021-09-15 14:52:03.136998200
+0200
+++ new/wayland-protocols-1.24/meson.build 2021-11-23 10:13:33.066573400
+0100
@@ -1,5 +1,5 @@
project('wayland-protocols',
- version: '1.23',
+ version: '1.24',
meson_version: '>= 0.54.0',
license: 'MIT/Expat',
)
@@ -8,8 +8,6 @@
fs = import('fs')
-dep_scanner = dependency('wayland-scanner', native: true)
-
stable_protocols = [
'presentation-time',
'viewporter',
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.23/stable/presentation-time/presentation-time.xml
new/wayland-protocols-1.24/stable/presentation-time/presentation-time.xml
--- old/wayland-protocols-1.23/stable/presentation-time/presentation-time.xml
2021-09-15 14:52:03.136998200 +0200
+++ new/wayland-protocols-1.24/stable/presentation-time/presentation-time.xml
2021-11-23 10:13:33.066573400 +0100
@@ -165,7 +165,7 @@
<description summary="presentation was vsync'd">
The presentation was synchronized to the "vertical retrace" by
the display hardware such that tearing does not happen.
- Relying on user space scheduling is not acceptable for this
+ Relying on software scheduling is not acceptable for this
flag. If presentation is done by a copy to the active
frontbuffer, then it must guarantee that tearing cannot
happen.
@@ -175,7 +175,7 @@
<description summary="hardware provided the presentation timestamp">
The display hardware provided measurements that the hardware
driver converted into a presentation timestamp. Sampling a
- clock in user space is not acceptable for this flag.
+ clock in software is not acceptable for this flag.
</description>
</entry>
<entry name="hw_completion" value="0x4">
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.23/stable/xdg-shell/xdg-shell.xml
new/wayland-protocols-1.24/stable/xdg-shell/xdg-shell.xml
--- old/wayland-protocols-1.23/stable/xdg-shell/xdg-shell.xml 2021-09-15
14:52:03.137998000 +0200
+++ new/wayland-protocols-1.24/stable/xdg-shell/xdg-shell.xml 2021-11-23
10:13:33.066573400 +0100
@@ -809,25 +809,25 @@
</description>
</entry>
<entry name="tiled_left" value="5" since="2">
- <description summary="the surface is tiled">
+ <description summary="the surface???s left edge is tiled">
The window is currently in a tiled layout and the left edge is
considered to be adjacent to another part of the tiling grid.
</description>
</entry>
<entry name="tiled_right" value="6" since="2">
- <description summary="the surface is tiled">
+ <description summary="the surface???s right edge is tiled">
The window is currently in a tiled layout and the right edge is
considered to be adjacent to another part of the tiling grid.
</description>
</entry>
<entry name="tiled_top" value="7" since="2">
- <description summary="the surface is tiled">
+ <description summary="the surface???s top edge is tiled">
The window is currently in a tiled layout and the top edge is
considered to be adjacent to another part of the tiling grid.
</description>
</entry>
<entry name="tiled_bottom" value="8" since="2">
- <description summary="the surface is tiled">
+ <description summary="the surface???s bottom edge is tiled">
The window is currently in a tiled layout and the bottom edge is
considered to be adjacent to another part of the tiling grid.
</description>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.23/tests/meson.build
new/wayland-protocols-1.24/tests/meson.build
--- old/wayland-protocols-1.23/tests/meson.build 2021-09-15
14:52:03.137998000 +0200
+++ new/wayland-protocols-1.24/tests/meson.build 2021-11-23
10:13:33.067573500 +0100
@@ -1,4 +1,5 @@
prog_scan_sh = find_program('scan.sh')
+dep_scanner = dependency('wayland-scanner', native: true)
prog_scanner =
find_program(dep_scanner.get_pkgconfig_variable('wayland_scanner'))
libwayland = [
@@ -20,9 +21,13 @@
# Check buildability
-add_languages('c', 'cpp', native: true)
+add_languages('c', 'cpp', native: false)
replace = find_program('replace.py')
+extra_linker_flags = meson.get_compiler('c').get_supported_link_arguments([
+ '-Wl,--unresolved-symbols=ignore-all',
+])
+
foreach protocol_file : protocol_files
xml_file = fs.name(protocol_file)
xml_components = xml_file.split('.')
@@ -99,9 +104,7 @@
server_header,
code
],
- link_args: [
- '-Wl,--unresolved-symbols=ignore-all',
- ],
+ link_args: extra_linker_flags,
dependencies: libwayland,
c_args: [
'-std=c99',
@@ -109,7 +112,6 @@
'-Wall',
'-Werror' ],
install: false,
- native: true,
)
test(test_name, pedantic_test_executable)
@@ -130,14 +132,13 @@
client_header,
server_header,
],
- link_args: [ '-Wl,--unresolved-symbols=ignore-all' ],
+ link_args: extra_linker_flags,
dependencies: libwayland,
cpp_args: [
'-Wall',
'-Werror',
],
install: false,
- native: true,
)
test(test_name, cxx_test_executable)
endif
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.23/unstable/linux-dmabuf/feedback.rst
new/wayland-protocols-1.24/unstable/linux-dmabuf/feedback.rst
--- old/wayland-protocols-1.23/unstable/linux-dmabuf/feedback.rst
1970-01-01 01:00:00.000000000 +0100
+++ new/wayland-protocols-1.24/unstable/linux-dmabuf/feedback.rst
2021-11-23 10:13:33.068573500 +0100
@@ -0,0 +1,218 @@
+.. Copyright 2021 Simon Ser
+
+.. contents::
+
+
+linux-dmabuf feedback introduction
+==================================
+
+linux-dmabuf feedback allows compositors and clients to negotiate optimal
buffer
+allocation parameters. This document will assume that the compositor is using a
+rendering API such as OpenGL or Vulkan and KMS as the presentation API: even if
+linux-dmabuf feedback isn't restricted to this use-case, it's the most common.
+
+linux-dmabuf feedback introduces the following concepts:
+
+1. A main device. This is the render device that the compositor is using to
+ perform composition. Compositors should always be able to display a buffer
+ submitted by a client, so this device can be used as a fallback in case none
+ of the more optimized code-paths work. Clients should allocate buffers such
+ that they can be imported and textured from the main device.
+
+2. One or more tranches. Each tranche consists of a target device, allocation
+ flags and a set of format/modifier pairs. A tranche can be seen as a set of
+ formats/modifier pairs that are compatible with the target device.
+
+ A tranche can have the ``scanout`` flag. It means that the target device is
+ a KMS device, and that buffers allocated with one of the format/modifier
+ pairs in the tranche are eligible for direct scanout.
+
+ Clients should use the tranches in order to allocate buffers with the most
+ appropriate format/modifier and also to avoid allocating in private device
+ memory when cross-device operations are going to happen.
+
+linux-dmabuf feedback implementation notes
+==========================================
+
+This section contains recommendations for client and compositor
implementations.
+
+For clients
+-----------
+
+Clients are expected to either pick a fixed DRM format beforehand, or
+perform the following steps repeatedly until they find a suitable format.
+
+Basic clients may only support static buffer allocation on startup. These
+clients should do the following:
+
+1. Send a ``get_default_feedback`` request to get global feedback.
+2. Select the device indicated by ``main_device`` for allocation.
+3. For each tranche:
+
+ 1. If ``tranche_target_device`` doesn't match the allocation device, ignore
+ the tranche.
+ 2. Accumulate allocation flags from ``tranche_flags``.
+ 3. Accumulate format/modifier pairs received via ``tranche_formats`` in a
+ list.
+ 4. When the ``tranche_done`` event is received, try to allocate the buffer
+ with the accumulated list of modifiers and allocation flags. If that
+ fails, proceed with the next tranche. If that succeeds, stop the loop.
+
+4. Destroy the feedback object.
+
+Tranches are ordered by preference: the more optimized tranches come first. As
+such, clients should use the first tranche that happens to work.
+
+Some clients may have already selected the device they want to use beforehand.
+These clients can ignore the ``main_device`` event, and ignore tranches whose
+``tranche_target_device`` doesn't match the selected device. Such clients need
+to be prepared for the ``wp_linux_buffer_params.create`` request to potentially
+fail.
+
+If the client allocates a buffer without specifying explicit modifiers on a
+device different from the one indicated by ``main_device``, then the client
+must force a linear layout.
+
+Some clients might support re-negotiating the buffer format/modifier on the
+fly. These clients should send a ``get_surface_feedback`` request and keep the
+feedback object alive after the initial allocation. Each time a new set of
+feedback parameters is received (ended by the ``done`` event), they should
+perform the same steps as basic clients described above. They should detect
+when the optimal allocation parameters didn't change (same
+format/modifier/flags) to avoid needlessly re-allocating their buffers.
+
+Some clients might additionally support switching the device used for
+allocations on the fly. Such clients should send a ``get_surface_feedback``
+request. For each tranche, select the device indicated by
+``tranche_target_device`` for allocation. Accumulate allocation flags (received
+via ``tranche_flags``) and format/modifier pairs (received via
+``tranche_formats``) as usual. When the ``tranche_done`` event is received, try
+to allocate the buffer with the accumulated list of modifiers and the
+allocation flags. Try to import the resulting buffer by sending a
+``wp_linux_buffer_params.create`` request (this might fail). Repeat with each
+tranche until an allocation and import succeeds. Each time a new set of
+feedback parameters is received, they should perform these steps again. They
+should detect when the optimal allocation parameters didn't change (same
+device/format/modifier/flags) to avoid needlessly re-allocating their buffers.
+
+For compositors
+---------------
+
+Basic compositors may only support texturing the DMA-BUFs via a rendering API
+such as OpenGL or Vulkan. Such compositors can send a single tranche as a reply
+to both ``get_default_feedback`` and ``get_surface_feedback``. Set the
+``main_device`` to the rendering device. Send the tranche with
+``tranche_target_device`` set to the rendering device and all of the DRM
+format/modifier pairs supported by the rendering API. Do not set the
+``scanout`` flag in the ``tranche_flags`` event.
+
+Some compositors may support direct scan-out for full-screen surfaces. These
+compositors can re-send the feedback parameters when a surface becomes
+full-screen or leaves full-screen mode if the client has used the
+``get_surface_feedback`` request. The non-full-screen feedback parameters are
+the same as basic compositors described above. The full-screen feedback
+parameters have two tranches: one with the format/modifier pairs supported by
+the KMS plane, with the ``scanout`` flag set in the ``tranche_flags`` event and
+with ``tranche_target_device`` set to the KMS scan-out device; the other with
+the rest of the format/modifier pairs (supported for texturing, but not for
+scan-out), without the ``scanout`` flag set in the ``tranche_flags`` event, and
+with the ``tranche_target_device`` set to the rendering device.
+
+Some compositors may support direct scan-out for all surfaces. These
+compositors can send two tranches for surfaces that become candidates for
+direct scan-out, similarly to compositors supporting direct scan-out for
+fullscreen surfaces. When a surface stops being a candidate for direct
+scan-out, compositors should re-send the feedback parameters optimized for
+texturing only. The way candidates for direct scan-out are selected is
+compositor policy, a possible implementation is to select as many surfaces as
+there are available hardware planes, starting from surfaces closer to the eye.
+
+Some compositors may support multiple devices at the same time. If the
+compositor supports rendering with a fixed device and direct scan-out on a
+secondary device, it may send a separate tranche for surfaces displayed on
+the secondary device that are candidates for direct scan-out. The
+``tranche_target_device`` for this tranche will be the secondary device and
+will not match the ``main_device``.
+
+Some compositors may support switching their rendering device at runtime or
+changing their rendering device depending on the surface. When the rendering
+device changes for a surface, such compositors may re-send the feedback
+parameters with a different ``main_device``. However there is a risk that
+clients don't support switching their device at runtime and continue using the
+previous device. For this reason, compositors should always have a fallback
+rendering device that they initially send as ``main_device``, such that these
+clients use said fallback device.
+
+Compositors should not change the ``main_device`` on-the-fly when explicit
+modifiers are not supported, because there's a risk of importing buffers
+with an implicit non-linear modifier as a linear buffer, resulting in
+misinterpreted buffer contents.
+
+Compositors should not send feedback parameters if they don't have a fallback
+path. For instance, compositors shouldn't send a format/modifier supported for
+direct scan-out but not supported by the rendering API for texturing.
+
+Compositors can decide to use multiple tranches to describe the allocation
+parameters optimized for texturing. For example, if there are formats which
+have a fast texturing path and formats which have a slower texturing path, the
+compositor can decide to expose two separate tranches.
+
+Compositors can decide to use intermediate tranches to describe code-paths
+slower than direct scan-out but faster than texturing. For instance, a
+compositor could insert an intermediate tranche if it's possible to use a
+mem2mem device to convert buffers to be able to use scan-out.
+
+``dev_t`` encoding
+==================
+
+The protocol carries ``dev_t`` values on the wire using arrays. A compositor
+written in C can encode the values as follows:
+
+.. code-block:: c
+
+ struct stat drm_node_stat;
+ struct wl_array dev_array = {
+ .size = sizeof(drm_node_stat.st_rdev),
+ .data = &drm_node_stat.st_rdev,
+ };
+
+A client can decode the values as follows:
+
+.. code-block:: c
+
+ struct dev_t dev;
+ assert(dev_array->size == sizeof(dev));
+ memcpy(&dev, dev_array->data, sizeof(dev));
+
+Because two DRM nodes can refer to the same DRM device while having different
+``dev_t`` values, clients should use ``drmDevicesEqual`` to compare two
+devices.
+
+``format_table`` encoding
+=========================
+
+The ``format_table`` event carries a file descriptor containing a list of
+format + modifier pairs. The list is an array of pairs which can be accessed
+with this C structure definition:
+
+.. code-block:: c
+
+ struct dmabuf_format_modifier {
+ uint32_t format;
+ uint32_t pad; /* unused */
+ uint64_t modifier;
+ };
+
+Integration with other APIs
+===========================
+
+- libdrm: ``drmGetDeviceFromDevId`` returns a ``drmDevice`` from a device ID.
+- EGL: the `EGL_EXT_device_drm_render_node`_ extension may be used to query the
+ DRM device render node used by a given EGL display. When unavailable, the
+ older `EGL_EXT_device_drm`_ extension may be used as a fallback.
+- Vulkan: the `VK_EXT_physical_device_drm`_ extension may be used to query the
+ DRM device used by a given ``VkPhysicalDevice``.
+
+.. _EGL_EXT_device_drm:
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_device_drm.txt
+.. _EGL_EXT_device_drm_render_node:
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_device_drm_render_node.txt
+.. _VK_EXT_physical_device_drm:
https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_physical_device_drm.html
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.23/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
new/wayland-protocols-1.24/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
---
old/wayland-protocols-1.23/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
2021-09-15 14:52:03.140998100 +0200
+++
new/wayland-protocols-1.24/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
2021-11-23 10:13:33.068573500 +0100
@@ -24,17 +24,18 @@
DEALINGS IN THE SOFTWARE.
</copyright>
- <interface name="zwp_linux_dmabuf_v1" version="3">
+ <interface name="zwp_linux_dmabuf_v1" version="4">
<description summary="factory for creating dmabuf-based wl_buffers">
Following the interfaces from:
https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.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.
+ This interface offers ways to create generic dmabuf-based wl_buffers.
+
+ Clients can use the get_surface_feedback request to get dmabuf feedback
+ for a particular surface. If the client wants to retrieve feedback not
+ tied to a surface, they can use the get_default_feedback request.
The following are required from clients:
@@ -82,6 +83,9 @@
client. If the client uses a failed wl_buffer as an argument to any
request, the behaviour is compositor implementation-defined.
+ For all DRM formats and unless specified in another protocol extension,
+ pre-multiplied alpha is used for pixel values.
+
Warning! The protocol described in this file is experimental and
backward incompatible changes may be made. Backward compatible changes
may be added together with the corresponding interface version bump.
@@ -120,10 +124,9 @@
For the definition of the format codes, see the
zwp_linux_buffer_params_v1::create request.
- Warning: the 'format' event is likely to be deprecated and replaced
- with the 'modifier' event introduced in zwp_linux_dmabuf_v1
- version 3, described below. Please refrain from using the information
- received from this event.
+ Starting version 4, the format event is deprecated and must not be
+ sent by compositors. Instead, use get_default_feedback or
+ get_surface_feedback.
</description>
<arg name="format" type="uint" summary="DRM_FORMAT code"/>
</event>
@@ -149,6 +152,10 @@
For the definition of the format and modifier codes, see the
zwp_linux_buffer_params_v1::create and zwp_linux_buffer_params_v1::add
requests.
+
+ Starting version 4, the modifier event is deprecated and must not be
+ sent by compositors. Instead, use get_default_feedback or
+ get_surface_feedback.
</description>
<arg name="format" type="uint" summary="DRM_FORMAT code"/>
<arg name="modifier_hi" type="uint"
@@ -156,9 +163,34 @@
<arg name="modifier_lo" type="uint"
summary="low 32 bits of layout modifier"/>
</event>
+
+ <!-- Version 4 additions -->
+
+ <request name="get_default_feedback" since="4">
+ <description summary="get default feedback">
+ This request creates a new wp_linux_dmabuf_feedback object not bound
+ to a particular surface. This object will deliver feedback about dmabuf
+ parameters to use if the client doesn't support per-surface feedback
+ (see get_surface_feedback).
+ </description>
+ <arg name="id" type="new_id" interface="zwp_linux_dmabuf_feedback_v1"/>
+ </request>
+
+ <request name="get_surface_feedback" since="4">
+ <description summary="get feedback for a surface">
+ This request creates a new wp_linux_dmabuf_feedback object for the
+ specified wl_surface. This object will deliver feedback about dmabuf
+ parameters to use for buffers attached to this surface.
+
+ If the surface is destroyed before the wp_linux_dmabuf_feedback object,
+ the feedback object becomes inert.
+ </description>
+ <arg name="id" type="new_id" interface="zwp_linux_dmabuf_feedback_v1"/>
+ <arg name="surface" type="object" interface="wl_surface"/>
+ </request>
</interface>
- <interface name="zwp_linux_buffer_params_v1" version="3">
+ <interface name="zwp_linux_buffer_params_v1" version="4">
<description summary="parameters for creating a dmabuf-based wl_buffer">
This temporary object is a collection of dmabufs and other
parameters that together form a single logical buffer. The temporary
@@ -215,10 +247,8 @@
compression, etc. driver-specific modifications to the base format
defined by the DRM fourcc code.
- Warning: It should be an error if the format/modifier pair was not
- advertised with the modifier event. This is not enforced yet because
- some implementations always accept DRM_FORMAT_MOD_INVALID. Also
- version 2 of this protocol does not have the modifier event.
+ Starting from version 4, the invalid_format protocol error is sent if
+ the format + modifier pair was not advertised as supported.
This request raises the PLANE_IDX error if plane_idx is too large.
The error PLANE_SET is raised if attempting to set a plane that
@@ -365,7 +395,192 @@
<arg name="format" type="uint" summary="DRM_FORMAT code"/>
<arg name="flags" type="uint" enum="flags" summary="see enum flags"/>
</request>
+ </interface>
+
+ <interface name="zwp_linux_dmabuf_feedback_v1" version="4">
+ <description summary="dmabuf feedback">
+ This object advertises dmabuf parameters feedback. This includes the
+ preferred devices and the supported formats/modifiers.
+
+ The parameters are sent once when this object is created and whenever
they
+ change. The done event is always sent once after all parameters have been
+ sent. When a single parameter changes, all parameters are re-sent by the
+ compositor.
+
+ Compositors can re-send the parameters when the current client buffer
+ allocations are sub-optimal. Compositors should not re-send the
+ parameters if re-allocating the buffers would not result in a more
optimal
+ configuration. In particular, compositors should avoid sending the exact
+ same parameters multiple times in a row.
+
+ The tranche_target_device and tranche_modifier events are grouped by
+ tranches of preference. For each tranche, a tranche_target_device, one
+ tranche_flags and one or more tranche_modifier events are sent, followed
+ by a tranche_done event finishing the list. The tranches are sent in
+ descending order of preference. All formats and modifiers in the same
+ tranche have the same preference.
+
+ To send parameters, the compositor sends one main_device event, tranches
+ (each consisting of one tranche_target_device event, one tranche_flags
+ event, tranche_modifier events and then a tranche_done event), then one
+ done event.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy the feedback object">
+ Using this request a client can tell the server that it is not going to
+ use the wp_linux_dmabuf_feedback object anymore.
+ </description>
+ </request>
+
+ <event name="done">
+ <description summary="all feedback has been sent">
+ This event is sent after all parameters of a wp_linux_dmabuf_feedback
+ object have been sent.
+
+ This allows changes to the wp_linux_dmabuf_feedback parameters to be
+ seen as atomic, even if they happen via multiple events.
+ </description>
+ </event>
+
+ <event name="format_table">
+ <description summary="format and modifier table">
+ This event provides a file descriptor which can be memory-mapped to
+ access the format and modifier table.
+
+ The table contains a tightly packed array of consecutive format +
+ modifier pairs. Each pair is 16 bytes wide. It contains a format as a
+ 32-bit unsigned integer, followed by 4 bytes of unused padding, and a
+ modifier as a 64-bit unsigned integer. The native endianness is used.
+
+ The client must map the file descriptor in read-only private mode.
+
+ Compositors are not allowed to mutate the table file contents once this
+ event has been sent. Instead, compositors must create a new, separate
+ table file and re-send feedback parameters. Compositors are allowed to
+ store duplicate format + modifier pairs in the table.
+ </description>
+ <arg name="fd" type="fd" summary="table file descriptor"/>
+ <arg name="size" type="uint" summary="table size, in bytes"/>
+ </event>
+
+ <event name="main_device">
+ <description summary="preferred main device">
+ This event advertises the main device that the server prefers to use
+ when direct scan-out to the target device isn't possible. The
+ advertised main device may be different for each
+ wp_linux_dmabuf_feedback object, and may change over time.
+
+ There is exactly one main device. The compositor must send at least
+ one preference tranche with tranche_target_device equal to main_device.
+
+ Clients need to create buffers that the main device can import and
+ read from, otherwise creating the dmabuf wl_buffer will fail (see the
+ wp_linux_buffer_params.create and create_immed requests for details).
+ The main device will also likely be kept active by the compositor,
+ so clients can use it instead of waking up another device for power
+ savings.
+
+ In general the device is a DRM node. The DRM node type (primary vs.
+ render) is unspecified. Clients must not rely on the compositor sending
+ a particular node type. Clients cannot check two devices for equality
+ by comparing the dev_t value.
+
+ If explicit modifiers are not supported and the client performs buffer
+ allocations on a different device than the main device, then the client
+ must force the buffer to have a linear layout.
+ </description>
+ <arg name="device" type="array" summary="device dev_t value"/>
+ </event>
+ <event name="tranche_done">
+ <description summary="a preference tranche has been sent">
+ This event splits tranche_target_device and tranche_modifier events in
+ preference tranches. It is sent after a set of tranche_target_device
+ and tranche_modifier events; it represents the end of a tranche. The
+ next tranche will have a lower preference.
+ </description>
+ </event>
+
+ <event name="tranche_target_device">
+ <description summary="target device">
+ This event advertises the target device that the server prefers to use
+ for a buffer created given this tranche. The advertised target device
+ may be different for each preference tranche, and may change over time.
+
+ There is exactly one target device per tranche.
+
+ The target device may be a scan-out device, for example if the
+ compositor prefers to directly scan-out a buffer created given this
+ tranche. The target device may be a rendering device, for example if
+ the compositor prefers to texture from said buffer.
+
+ The client can use this hint to allocate the buffer in a way that makes
+ it accessible from the target device, ideally directly. The buffer must
+ still be accessible from the main device, either through direct import
+ or through a potentially more expensive fallback path. If the buffer
+ can't be directly imported from the main device then clients must be
+ prepared for the compositor changing the tranche priority or making
+ wl_buffer creation fail (see the wp_linux_buffer_params.create and
+ create_immed requests for details).
+
+ If the device is a DRM node, the DRM node type (primary vs. render) is
+ unspecified. Clients must not rely on the compositor sending a
+ particular node type. Clients cannot check two devices for equality by
+ comparing the dev_t value.
+
+ This event is tied to a preference tranche, see the tranche_done event.
+ </description>
+ <arg name="device" type="array" summary="device dev_t value"/>
+ </event>
+
+ <event name="tranche_formats">
+ <description summary="supported buffer format modifier">
+ This event advertises the format + modifier combinations that the
+ compositor supports.
+
+ It carries an array of indices, each referring to a format + modifier
+ pair in the last received format table (see the format_table event).
+ Each index is a 16-bit unsigned integer in native endianness.
+
+ For legacy support, DRM_FORMAT_MOD_INVALID is an allowed modifier.
+ It indicates that the server can support the format with an implicit
+ modifier. When a buffer has DRM_FORMAT_MOD_INVALID as its modifier, it
+ is as if no explicit modifier is specified. The effective modifier
+ will be derived from the dmabuf.
+
+ A compositor that sends valid modifiers and DRM_FORMAT_MOD_INVALID for
+ a given format supports both explicit modifiers and implicit modifiers.
+
+ Compositors must not send duplicate format + modifier pairs within the
+ same tranche or across two different tranches with the same target
+ device and flags.
+
+ This event is tied to a preference tranche, see the tranche_done event.
+
+ For the definition of the format and modifier codes, see the
+ wp_linux_buffer_params.create request.
+ </description>
+ <arg name="indices" type="array" summary="array of 16-bit indexes"/>
+ </event>
+
+ <enum name="tranche_flags" bitfield="true">
+ <entry name="scanout" value="1" summary="direct scan-out tranche"/>
+ </enum>
+
+ <event name="tranche_flags">
+ <description summary="tranche flags">
+ This event sets tranche-specific flags.
+
+ The scanout flag is a hint that direct scan-out may be attempted by the
+ compositor on the target device if the client appropriately allocates a
+ buffer. How to allocate a buffer that can be scanned out on the target
+ device is implementation-defined.
+
+ This event is tied to a preference tranche, see the tranche_done event.
+ </description>
+ <arg name="flags" type="uint" enum="tranche_flags" summary="tranche
flags"/>
+ </event>
</interface>
</protocol>
++++++
wayland-protocols-disable-pedantic-test-unstable-xdg-decoration-on-ppc64.patch
++++++
--- /var/tmp/diff_new_pack.cEXE3e/_old 2021-11-27 00:51:20.186799565 +0100
+++ /var/tmp/diff_new_pack.cEXE3e/_new 2021-11-27 00:51:20.186799565 +0100
@@ -1,8 +1,8 @@
-Index: wayland-protocols-1.23/tests/meson.build
-===================================================================
---- wayland-protocols-1.23.orig/tests/meson.build
-+++ wayland-protocols-1.23/tests/meson.build
-@@ -6,6 +6,8 @@ libwayland = [
+diff --git a/tests/meson.build b/tests/meson.build
+index 5439239..cbb147c 100644
+--- a/tests/meson.build
++++ b/tests/meson.build
+@@ -7,6 +7,8 @@ libwayland = [
dependency('wayland-server'),
]
@@ -11,9 +11,9 @@
# Check that each protocol passes through the scanner
foreach protocol_file : protocol_files
protocol_path = join_paths(wayland_protocols_srcdir, protocol_file)
-@@ -111,7 +113,12 @@ foreach protocol_file : protocol_files
+@@ -113,7 +115,12 @@ foreach protocol_file : protocol_files
+ '-Werror' ],
install: false,
- native: true,
)
- test(test_name, pedantic_test_executable)
+
