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-09-16 23:14:33
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/wayland-protocols (Old)
and /work/SRC/openSUSE:Factory/.wayland-protocols.new.1899 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "wayland-protocols"
Thu Sep 16 23:14:33 2021 rev:23 rq:918403 version:1.22
Changes:
--------
--- /work/SRC/openSUSE:Factory/wayland-protocols/wayland-protocols.changes
2021-05-18 18:26:45.474880372 +0200
+++
/work/SRC/openSUSE:Factory/.wayland-protocols.new.1899/wayland-protocols.changes
2021-09-16 23:16:56.487939293 +0200
@@ -1,0 +2,20 @@
+Wed Sep 1 17:58:37 UTC 2021 - Christophe Giboudeaux <christo...@krop.fr>
+
+- Update to 1.22
+ This release includes a new staging protocol: DRM object leasing.
+
+ Besides that, various test and build system improvements are
+ included, as well as a set of clarifications to the
+ xdg-activation protocol and other protocols.
+
+ * xdg-shell: Make xdg_surface fail when surface has role
+ * xdg-output: fix minor calculation error
+ * xdg-activation: correct sequence when X11 client spawns
+ Wayland client
+ * xdg-activation: rewrite and move description of token forwarding
+ * xdg-activation-v1: clarify set_{serial,surface}
+ * presentation-time: use enum entry description tags
+- Check
https://lists.freedesktop.org/archives/wayland-devel/2021-September/041972.html
+ for the full list of changes.
+
+-------------------------------------------------------------------
Old:
----
wayland-protocols-1.21.tar.xz
wayland-protocols-1.21.tar.xz.sig
New:
----
wayland-protocols-1.22.tar.xz
wayland-protocols-1.22.tar.xz.sig
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ wayland-protocols.spec ++++++
--- /var/tmp/diff_new_pack.qLXGRN/_old 2021-09-16 23:16:57.111939939 +0200
+++ /var/tmp/diff_new_pack.qLXGRN/_new 2021-09-16 23:16:57.115939943 +0200
@@ -18,7 +18,7 @@
Name: wayland-protocols
-Version: 1.21
+Version: 1.22
Release: 0
Summary: Wayland protocols that adds functionality not available in the
core protocol
License: MIT
++++++ wayland-protocols-1.21.tar.xz -> wayland-protocols-1.22.tar.xz ++++++
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.21/MEMBERS.md
new/wayland-protocols-1.22/MEMBERS.md
--- old/wayland-protocols-1.21/MEMBERS.md 2021-03-31 08:35:19.000000000
+0200
+++ new/wayland-protocols-1.22/MEMBERS.md 2021-09-01 09:24:41.000000000
+0200
@@ -1,13 +1,15 @@
# wayland-protocols members
-- EFL/Enlightenment: Mike Blumenkrantz <michael.blumenkra...@gmail.com>
-- GTK/Mutter: Jonas ??dahl <jad...@gmail.com>,
- Carlos Garnacho <carl...@gnome.org>
-- KWin: Eike Hein <h...@kde.org>,
- David Edmundson <da...@davidedmundson.co.uk>
-- Mir: Christopher James Halse Rogers <r...@ubuntu.com>,
+- EFL/Enlightenment: Mike Blumenkrantz <michael.blumenkra...@gmail.com>
(@zmike)
+- GTK/Mutter: Jonas ??dahl <jad...@gmail.com> (@jadahl),
+ Carlos Garnacho <carl...@gnome.org> (@carlosg)
+- KWin: Eike Hein <h...@kde.org> (@hein),
+ David Edmundson <da...@davidedmundson.co.uk> (@davidedmundson)
+- Mir: Christopher James Halse Rogers <r...@ubuntu.com> (@RAOF),
Alan Griffiths <alan.griffi...@canonical.com>
- Qt: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfe...@qt.io>
-- Weston: Pekka Paalanen <pekka.paala...@collabora.com>,
- Daniel Stone <dan...@fooishbar.org>
-- wlroots/Sway: Drew DeVault <s...@cmpwn.com>, Simon Ser <cont...@emersion.fr>
+ (@eskilblomfeldt)
+- Weston: Pekka Paalanen <pekka.paala...@collabora.com> (@pq),
+ Daniel Stone <dan...@fooishbar.org> (@daniels)
+- wlroots/Sway: Drew DeVault <s...@cmpwn.com> (@ddevault),
+ Simon Ser <cont...@emersion.fr> (@emersion)
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.21/Makefile.am
new/wayland-protocols-1.22/Makefile.am
--- old/wayland-protocols-1.21/Makefile.am 2021-04-30 16:11:07.000000000
+0200
+++ new/wayland-protocols-1.22/Makefile.am 2021-09-01 09:24:41.000000000
+0200
@@ -32,6 +32,7 @@
$(NULL)
staging_protocols =
\
+ staging/drm-lease/drm-lease-v1.xml
\
staging/xdg-activation/xdg-activation-v1.xml
\
$(NULL)
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.21/Makefile.in
new/wayland-protocols-1.22/Makefile.in
--- old/wayland-protocols-1.21/Makefile.in 2021-04-30 18:09:40.000000000
+0200
+++ new/wayland-protocols-1.22/Makefile.in 2021-09-01 09:45:55.000000000
+0200
@@ -336,7 +336,8 @@
am__EXEEXT_2 = stable/presentation-time/presentation-time.xml \
stable/viewporter/viewporter.xml \
stable/xdg-shell/xdg-shell.xml
-am__EXEEXT_3 = staging/xdg-activation/xdg-activation-v1.xml
+am__EXEEXT_3 = staging/drm-lease/drm-lease-v1.xml \
+ staging/xdg-activation/xdg-activation-v1.xml
TEST_SUITE_LOG = test-suite.log
am__test_logs1 = $(TESTS:=.log)
TEST_LOGS = $(am__test_logs1:.xml.log=.log)
@@ -489,6 +490,7 @@
$(NULL)
staging_protocols = \
+ staging/drm-lease/drm-lease-v1.xml
\
staging/xdg-activation/xdg-activation-v1.xml
\
$(NULL)
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.21/README.md
new/wayland-protocols-1.22/README.md
--- old/wayland-protocols-1.21/README.md 2021-03-31 11:20:59.000000000
+0200
+++ new/wayland-protocols-1.22/README.md 2021-09-01 09:24:41.000000000
+0200
@@ -89,6 +89,12 @@
To propose changes to existing protocols, create a GitLab merge request.
+Please include a `Signed-off-by` line at the end of the commit to certify
+that you wrote it or otherwise have the right to pass it on as an
+open-source patch. See the
+[Developer Certificate of Origin](https://developercertificate.org/) for
+a formal definition.
+
## Interface naming convention
All protocols should avoid using generic namespaces or no namespaces in
@@ -223,9 +229,9 @@
When merge requests get their needed feedback and items, remove the
corresponding label that marks it as needing something. For example, if a
-merge request receives all the required acknowledgments, remove the ~"Needs
-acks" label, or if 30 days passed since opening, remove any ~"In 30 days
-discussion period" label.
+merge request receives all the required acknowledgments, remove the
+~"Needs acks" label, or if 30 days passed since opening, remove any
+~"In 30 day discussion period" label.
### Nacking a merge request
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.21/configure
new/wayland-protocols-1.22/configure
--- old/wayland-protocols-1.21/configure 2021-04-30 18:09:40.000000000
+0200
+++ new/wayland-protocols-1.22/configure 2021-09-01 09:45:55.000000000
+0200
@@ -1,6 +1,6 @@
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for wayland-protocols 1.21.
+# Generated by GNU Autoconf 2.69 for wayland-protocols 1.22.
#
# Report bugs to
<https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=wayland&version=unspecified>.
#
@@ -580,8 +580,8 @@
# Identity of this package.
PACKAGE_NAME='wayland-protocols'
PACKAGE_TARNAME='wayland-protocols'
-PACKAGE_VERSION='1.21'
-PACKAGE_STRING='wayland-protocols 1.21'
+PACKAGE_VERSION='1.22'
+PACKAGE_STRING='wayland-protocols 1.22'
PACKAGE_BUGREPORT='https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=wayland&version=unspecified'
PACKAGE_URL='http://wayland.freedesktop.org/'
@@ -1226,7 +1226,7 @@
# Omit some internal or obsolete options to make the list less imposing.
# This message is too long to be a string in the A/UX 3.1 sh.
cat <<_ACEOF
-\`configure' configures wayland-protocols 1.21 to adapt to many kinds of
systems.
+\`configure' configures wayland-protocols 1.22 to adapt to many kinds of
systems.
Usage: $0 [OPTION]... [VAR=VALUE]...
@@ -1294,7 +1294,7 @@
if test -n "$ac_init_help"; then
case $ac_init_help in
- short | recursive ) echo "Configuration of wayland-protocols 1.21:";;
+ short | recursive ) echo "Configuration of wayland-protocols 1.22:";;
esac
cat <<\_ACEOF
@@ -1392,7 +1392,7 @@
test -n "$ac_init_help" && exit $ac_status
if $ac_init_version; then
cat <<\_ACEOF
-wayland-protocols configure 1.21
+wayland-protocols configure 1.22
generated by GNU Autoconf 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
@@ -1409,7 +1409,7 @@
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
-It was created by wayland-protocols $as_me 1.21, which was
+It was created by wayland-protocols $as_me 1.22, which was
generated by GNU Autoconf 2.69. Invocation command line was
$ $0 $@
@@ -1760,7 +1760,7 @@
-WAYLAND_PROTOCOLS_VERSION=1.21
+WAYLAND_PROTOCOLS_VERSION=1.22
@@ -2539,7 +2539,7 @@
# Define the identity of the package.
PACKAGE='wayland-protocols'
- VERSION='1.21'
+ VERSION='1.22'
cat >>confdefs.h <<_ACEOF
@@ -3358,7 +3358,7 @@
# report actual input values of CONFIG_FILES etc. instead of their
# values after options handling.
ac_log="
-This file was extended by wayland-protocols $as_me 1.21, which was
+This file was extended by wayland-protocols $as_me 1.22, which was
generated by GNU Autoconf 2.69. Invocation command line was
CONFIG_FILES = $CONFIG_FILES
@@ -3412,7 +3412,7 @@
cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //;
s/[\\""\`\$]/\\\\&/g'`"
ac_cs_version="\\
-wayland-protocols config.status 1.21
+wayland-protocols config.status 1.22
configured by $0, generated by GNU Autoconf 2.69,
with options \\"\$ac_cs_config\\"
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.21/configure.ac
new/wayland-protocols-1.22/configure.ac
--- old/wayland-protocols-1.21/configure.ac 2021-04-30 18:09:17.000000000
+0200
+++ new/wayland-protocols-1.22/configure.ac 2021-09-01 09:45:22.000000000
+0200
@@ -1,7 +1,7 @@
AC_PREREQ([2.64])
m4_define([wayland_protocols_major_version], [1])
-m4_define([wayland_protocols_minor_version], [21])
+m4_define([wayland_protocols_minor_version], [22])
m4_define([wayland_protocols_version],
[wayland_protocols_major_version.wayland_protocols_minor_version])
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.21/meson.build
new/wayland-protocols-1.22/meson.build
--- old/wayland-protocols-1.21/meson.build 2021-04-30 18:09:21.000000000
+0200
+++ new/wayland-protocols-1.22/meson.build 2021-09-01 09:43:24.000000000
+0200
@@ -1,6 +1,6 @@
project('wayland-protocols',
- version: '1.21',
- meson_version: '>= 0.53.0',
+ version: '1.22',
+ meson_version: '>= 0.54.0',
license: 'MIT/Expat',
)
@@ -39,6 +39,7 @@
staging_protocols = {
'xdg-activation': ['v1'],
+ 'drm-lease': ['v1'],
}
protocol_files = []
@@ -106,6 +107,14 @@
configuration: pkgconfig_configuration,
)
+wayland_protocols = declare_dependency(
+ variables: {
+ 'pkgdatadir': wayland_protocols_srcdir,
+ },
+)
+
+meson.override_dependency('wayland-protocols', wayland_protocols)
+
if get_option('tests')
subdir('tests')
endif
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.21/stable/presentation-time/presentation-time.xml
new/wayland-protocols-1.22/stable/presentation-time/presentation-time.xml
--- old/wayland-protocols-1.21/stable/presentation-time/presentation-time.xml
2021-03-31 08:35:19.000000000 +0200
+++ new/wayland-protocols-1.22/stable/presentation-time/presentation-time.xml
2021-09-01 09:24:41.000000000 +0200
@@ -159,43 +159,43 @@
These flags provide information about how the presentation of
the related content update was done. The intent is to help
clients assess the reliability of the feedback and the visual
- quality with respect to possible tearing and timings. The
- flags are:
-
- VSYNC:
- 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
- flag. If presentation is done by a copy to the active
- frontbuffer, then it must guarantee that tearing cannot
- happen.
-
- HW_CLOCK:
- 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.
-
- HW_COMPLETION:
- The display hardware signalled that it started using the new
- image content. The opposite of this is e.g. a timer being used
- to guess when the display hardware has switched to the new
- image content.
-
- ZERO_COPY:
- The presentation of this update was done zero-copy. This means
- the buffer from the client was given to display hardware as
- is, without copying it. Compositing with OpenGL counts as
- copying, even if textured directly from the client buffer.
- Possible zero-copy cases include direct scanout of a
- fullscreen surface and a surface on a hardware overlay.
+ quality with respect to possible tearing and timings.
</description>
- <entry name="vsync" value="0x1" summary="presentation was vsync'd"/>
- <entry name="hw_clock" value="0x2"
- summary="hardware provided the presentation timestamp"/>
- <entry name="hw_completion" value="0x4"
- summary="hardware signalled the start of the presentation"/>
- <entry name="zero_copy" value="0x8"
- summary="presentation was done zero-copy"/>
+ <entry name="vsync" value="0x1">
+ <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
+ flag. If presentation is done by a copy to the active
+ frontbuffer, then it must guarantee that tearing cannot
+ happen.
+ </description>
+ </entry>
+ <entry name="hw_clock" value="0x2">
+ <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.
+ </description>
+ </entry>
+ <entry name="hw_completion" value="0x4">
+ <description summary="hardware signalled the start of the
presentation">
+ The display hardware signalled that it started using the new
+ image content. The opposite of this is e.g. a timer being used
+ to guess when the display hardware has switched to the new
+ image content.
+ </description>
+ </entry>
+ <entry name="zero_copy" value="0x8">
+ <description summary="presentation was done zero-copy">
+ The presentation of this update was done zero-copy. This means
+ the buffer from the client was given to display hardware as
+ is, without copying it. Compositing with OpenGL counts as
+ copying, even if textured directly from the client buffer.
+ Possible zero-copy cases include direct scanout of a
+ fullscreen surface and a surface on a hardware overlay.
+ </description>
+ </entry>
</enum>
<event name="presented">
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.21/stable/xdg-shell/xdg-shell.xml
new/wayland-protocols-1.22/stable/xdg-shell/xdg-shell.xml
--- old/wayland-protocols-1.21/stable/xdg-shell/xdg-shell.xml 2021-03-26
10:11:47.000000000 +0100
+++ new/wayland-protocols-1.22/stable/xdg-shell/xdg-shell.xml 2021-09-01
09:24:41.000000000 +0200
@@ -75,7 +75,9 @@
<description summary="create a shell surface from a surface">
This creates an xdg_surface for the given surface. While xdg_surface
itself is not a role, the corresponding surface may only be assigned
- a role extending xdg_surface, such as xdg_toplevel or xdg_popup.
+ a role extending xdg_surface, such as xdg_toplevel or xdg_popup. It is
+ illegal to create an xdg_surface for a wl_surface which already has an
+ assigned role and this will result in a protocol error.
This creates an xdg_surface for the given surface. An xdg_surface is
used as basis to define a role to a given surface, such as xdg_toplevel
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.21/staging/drm-lease/README
new/wayland-protocols-1.22/staging/drm-lease/README
--- old/wayland-protocols-1.21/staging/drm-lease/README 1970-01-01
01:00:00.000000000 +0100
+++ new/wayland-protocols-1.22/staging/drm-lease/README 2021-09-01
09:24:41.000000000 +0200
@@ -0,0 +1,6 @@
+Linux DRM lease
+
+Maintainers:
+Drew DeVault <s...@cmpwn.com>
+Marius Vlad <marius.v...@collabora.com>
+Xaver Hugl <xaver.h...@gmail.com>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.21/staging/drm-lease/drm-lease-v1.xml
new/wayland-protocols-1.22/staging/drm-lease/drm-lease-v1.xml
--- old/wayland-protocols-1.21/staging/drm-lease/drm-lease-v1.xml
1970-01-01 01:00:00.000000000 +0100
+++ new/wayland-protocols-1.22/staging/drm-lease/drm-lease-v1.xml
2021-09-01 09:24:41.000000000 +0200
@@ -0,0 +1,303 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="drm_lease_v1">
+ <copyright>
+ Copyright ?? 2018 NXP
+ Copyright ?? 2019 Status Research & Development GmbH.
+ Copyright ?? 2021 Xaver Hugl
+
+ 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.
+ </copyright>
+
+ <interface name="wp_drm_lease_device_v1" version="1">
+ <description summary="lease device">
+ This protocol is used by Wayland compositors which act as Direct
+ Renderering Manager (DRM) masters to lease DRM resources to Wayland
+ clients.
+
+ The compositor will advertise one wp_drm_lease_device_v1 global for each
+ DRM node. Some time after a client binds to the wp_drm_lease_device_v1
+ global, the compositor will send a drm_fd event followed by zero, one or
+ more connector events. After all currently available connectors have been
+ sent, the compositor will send a wp_drm_lease_device_v1.done event.
+
+ When the list of connectors available for lease changes the compositor
+ will send wp_drm_lease_device_v1.connector events for added connectors
and
+ wp_drm_lease_connector_v1.withdrawn events for removed connectors,
+ followed by a wp_drm_lease_device_v1.done event.
+
+ The compositor will indicate when a device is gone by removing the global
+ via a wl_registry.global_remove event. Upon receiving this event, the
+ client should destroy any matching wp_drm_lease_device_v1 object.
+
+ To destroy a wp_drm_lease_device_v1 object, the client must first issue
+ a release request. Upon receiving this request, the compositor will
+ immediately send a released event and destroy the object. The client must
+ continue to process and discard drm_fd and connector events until it
+ receives the released event. Upon receiving the released event, the
+ client can safely cleanup any client-side resources.
+
+ Warning! The protocol described in this file is currently in the testing
+ phase. Backward compatible changes may be added together with the
+ corresponding interface version bump. Backward incompatible changes can
+ only be done by creating a new major version of the extension.
+ </description>
+
+ <request name="create_lease_request">
+ <description summary="create a lease request object">
+ Creates a lease request object.
+
+ See the documentation for wp_drm_lease_request_v1 for details.
+ </description>
+ <arg name="id" type="new_id" interface="wp_drm_lease_request_v1" />
+ </request>
+
+ <request name="release">
+ <description summary="release this object">
+ Indicates the client no longer wishes to use this object. In response
+ the compositor will immediately send the released event and destroy
+ this object. It can however not guarantee that the client won't receive
+ connector events before the released event. The client must not send
any
+ requests after this one, doing so will raise a wl_display error.
+ Existing connectors, lease request and leases will not be affected.
+ </description>
+ </request>
+
+ <event name="drm_fd">
+ <description summary="open a non-master fd for this DRM node">
+ The compositor will send this event when the wp_drm_lease_device_v1
+ global is bound, although there are no guarantees as to how long this
+ takes - the compositor might need to wait until regaining DRM master.
+ The included fd is a non-master DRM file descriptor opened for this
+ device and the compositor must not authenticate it.
+ The purpose of this event is to give the client the ability to
+ query DRM and discover information which may help them pick the
+ appropriate DRM device or select the appropriate connectors therein.
+ </description>
+ <arg name="fd" type="fd" summary="DRM file descriptor" />
+ </event>
+
+ <event name="connector">
+ <description summary="advertise connectors available for leases">
+ The compositor will use this event to advertise connectors available
for
+ lease by clients. This object may be passed into a lease request to
+ indicate the client would like to lease that connector, see
+ wp_drm_lease_request_v1.request_connector for details. While the
+ compositor will make a best effort to not send disconnected connectors,
+ no guarantees can be made.
+
+ The compositor must send the drm_fd event before sending connectors.
+ After the drm_fd event it will send all available connectors but may
+ send additional connectors at any time.
+ </description>
+ <arg name="id" type="new_id" interface="wp_drm_lease_connector_v1" />
+ </event>
+
+ <event name="done">
+ <description summary="signals grouping of connectors">
+ The compositor will send this event to indicate that it has sent all
+ currently available connectors after the client binds to the global or
+ when it updates the connector list, for example on hotplug, drm master
+ change or when a leased connector becomes available again. It will
+ similarly send this event to group wp_drm_lease_connector_v1.withdrawn
+ events of connectors of this device.
+ </description>
+ </event>
+
+ <event name="released">
+ <description summary="the compositor has finished using the device">
+ This event is sent in response to the release request and indicates
+ that the compositor is done sending connector events.
+ The compositor will destroy this object immediately after sending the
+ event and it will become invalid. The client should release any
+ resources associated with this device after receiving this event.
+ </description>
+ </event>
+ </interface>
+
+ <interface name="wp_drm_lease_connector_v1" version="1">
+ <description summary="a leasable DRM connector">
+ Represents a DRM connector which is available for lease. These objects
are
+ created via wp_drm_lease_device_v1.connector events, and should be passed
+ to lease requests via wp_drm_lease_request_v1.request_connector.
+ Immediately after the wp_drm_lease_connector_v1 object is created the
+ compositor will send a name, a description, a connector_id and a done
+ event. When the description is updated the compositor will send a
+ description event followed by a done event.
+ </description>
+
+ <event name="name">
+ <description summary="name">
+ The compositor sends this event once the connector is created to
+ indicate the name of this connector. This will not change for the
+ duration of the Wayland session, but is not guaranteed to be consistent
+ between sessions.
+ </description>
+ <arg name="name" type="string" summary="connector name" />
+ </event>
+
+ <event name="description">
+ <description summary="description">
+ The compositor sends this event once the connector is created to
provide
+ a human-readable description for this connector, which may be presented
+ to the user. The compositor may send this event multiple times over the
+ lifetime of this object to reflect changes in the description.
+ </description>
+ <arg name="description" type="string" summary="connector description" />
+ </event>
+
+ <event name="connector_id">
+ <description summary="connector_id">
+ The compositor sends this event once the connector is created to
+ indicate the DRM object ID which represents the underlying connector
+ that is being offered. Note that the final lease may include additional
+ object IDs, such as CRTCs and planes.
+ </description>
+ <arg name="connector_id" type="uint" summary="DRM connector ID" />
+ </event>
+
+ <event name="done">
+ <description summary="all properties have been sent">
+ This event is sent after all properties of a connector have been sent.
+ This allows changes to the properties to be seen as atomic even if they
+ happen via multiple events.
+ </description>
+ </event>
+
+ <event name="withdrawn">
+ <description summary="lease offer withdrawn">
+ Sent to indicate that the compositor will no longer honor requests for
+ DRM leases which include this connector. The client may still issue a
+ lease request including this connector, but the compositor will send
+ wp_drm_lease_v1.finished without issuing a lease fd. Compositors are
+ encouraged to send this event when they lose access to connector, for
+ example when the connector is hot-unplugged, when the connector gets
+ leased to a client or when the compositor loses DRM master.
+ </description>
+ </event>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy connector">
+ The client may send this request to indicate that it will not use this
+ connector. Clients are encouraged to send this after receiving the
+ "withdrawn" event so that the server can release the resources
+ associated with this connector offer. Neither existing lease requests
+ nor leases will be affected.
+ </description>
+ </request>
+ </interface>
+
+ <interface name="wp_drm_lease_request_v1" version="1">
+ <description summary="DRM lease request">
+ A client that wishes to lease DRM resources will attach the list of
+ connectors advertised with wp_drm_lease_device_v1.connector that they
+ wish to lease, then use wp_drm_lease_request_v1.submit to submit the
+ request.
+ </description>
+
+ <enum name="error">
+ <entry name="wrong_device" value="0"
+ summary="requested a connector from a different lease device"/>
+ <entry name="duplicate_connector" value="1"
+ summary="requested a connector twice"/>
+ <entry name="empty_lease" value="2"
+ summary="requested a lease without requesting a connector"/>
+ </enum>
+
+ <request name="request_connector">
+ <description summary="request a connector for this lease">
+ Indicates that the client would like to lease the given connector.
+ This is only used as a suggestion, the compositor may choose to
+ include any resources in the lease it issues, or change the set of
+ leased resources at any time. Compositors are however encouraged to
+ include the requested connector and other resources necessary
+ to drive the connected output in the lease.
+
+ Requesting a connector that was created from a different lease device
+ than this lease request raises the wrong_device error. Requesting a
+ connector twice will raise the duplicate_connector error.
+ </description>
+ <arg name="connector" type="object"
+ interface="wp_drm_lease_connector_v1" />
+ </request>
+
+ <request name="submit" type="destructor">
+ <description summary="submit the lease request">
+ Submits the lease request and creates a new wp_drm_lease_v1 object.
+ After calling submit the compositor will immediately destroy this
+ object, issuing any more requests will cause a wl_diplay error.
+ The compositor doesn't make any guarantees about the events of the
+ lease object, clients cannot expect an immediate response.
+ Not requesting any connectors before submitting the lease request
+ will raise the empty_lease error.
+ </description>
+ <arg name="id" type="new_id" interface="wp_drm_lease_v1" />
+ </request>
+ </interface>
+
+ <interface name="wp_drm_lease_v1" version="1">
+ <description summary="a DRM lease">
+ A DRM lease object is used to transfer the DRM file descriptor to the
+ client and manage the lifetime of the lease.
+
+ Some time after the wp_drm_lease_v1 object is created, the compositor
+ will reply with the lease request's result. If the lease request is
+ granted, the compositor will send a lease_fd event. If the lease request
+ is denied, the compositor will send a finished event without a lease_fd
+ event.
+ </description>
+
+ <event name="lease_fd">
+ <description summary="shares the DRM file descriptor">
+ This event returns a file descriptor suitable for use with DRM-related
+ ioctls. The client should use drmModeGetLease to enumerate the DRM
+ objects which have been leased to them. The compositor guarantees it
+ will not use the leased DRM objects itself until it sends the finished
+ event. If the compositor cannot or will not grant a lease for the
+ requested connectors, it will not send this event, instead sending the
+ finished event.
+
+ The compositor will send this event at most once during this objects
+ lifetime.
+ </description>
+ <arg name="leased_fd" type="fd" summary="leased DRM file descriptor" />
+ </event>
+
+ <event name="finished">
+ <description summary="sent when the lease has been revoked">
+ The compositor uses this event to either reject a lease request, or if
+ it previously sent a lease_fd, to notify the client that the lease has
+ been revoked. If the client requires a new lease, they should destroy
+ this object and submit a new lease request. The compositor will send
+ no further events for this object after sending the finish event.
+ Compositors should revoke the lease when any of the leased resources
+ become unavailable, namely when a hot-unplug occurs or when the
+ compositor loses DRM master.
+ </description>
+ </event>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroys the lease object">
+ The client should send this to indicate that it no longer wishes to use
+ this lease. The compositor should use drmModeRevokeLease on the
+ appropriate file descriptor, if necessary.
+ </description>
+ </request>
+ </interface>
+</protocol>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.21/staging/xdg-activation/x11-interoperation.rst
new/wayland-protocols-1.22/staging/xdg-activation/x11-interoperation.rst
--- old/wayland-protocols-1.21/staging/xdg-activation/x11-interoperation.rst
2021-04-30 16:04:09.000000000 +0200
+++ new/wayland-protocols-1.22/staging/xdg-activation/x11-interoperation.rst
2021-09-01 09:24:41.000000000 +0200
@@ -3,14 +3,14 @@
*This document is non-normative.*
-The former X11 startup-notification standard
-(https://cgit.freedesktop.org/startup-notification/tree/doc/startup-notification.txt)
-defines the use of the DESKTOP_STARTUP_ID environment variable to propagate
+The former
+`X11 Startup notification protocol
<https://cgit.freedesktop.org/startup-notification/tree/doc/startup-notification.txt>`_
+defines the use of the ``DESKTOP_STARTUP_ID`` environment variable to propagate
startup sequences ("activation tokens" in this protocol) between launcher and
launchee.
These startup sequence IDs are defined as a globally unique string with a
-`[unique]_TIME[timestamp]` format, where the ID as a whole is used for startup
+``[unique]_TIME[timestamp]`` format, where the ID as a whole is used for
startup
notification and the timestamp is used for focus requests and focus stealing
prevention.
@@ -22,11 +22,11 @@
--------------------------------------------
1. Wayland client requests token.
-2. Wayland client spawns X11 client, sets `$DESKTOP_STARTUP_ID` in its
+2. Wayland client spawns X11 client, sets ``$DESKTOP_STARTUP_ID`` in its
environment with the token string.
3. X11 client starts.
-4. X11 client sends startup-notification `remove` message with the activation
- `$DESKTOP_STARTUP_ID` content.
+4. X11 client sends startup-notification ``remove`` message with the activation
+ ``$DESKTOP_STARTUP_ID`` content.
5. Compositor receives startup notification message, matches ID with
the common pool.
6. The startup feedback is finished.
@@ -37,28 +37,27 @@
--------------------------------------------
1. X11 client builds a "globally unique" ID
-2. X11 client sends startup-notification `new` message with the ID.
+2. X11 client sends startup-notification ``new`` message with the ID.
3. Compositor receives startup notification message, adds the ID to
the common pool.
-4. X11 client spawns Wayland client, sets `$DESKTOP_STARTUP_ID` in its
+4. X11 client spawns Wayland client, sets ``$DESKTOP_STARTUP_ID`` in its
environment.
5. Wayland client starts.
-6. Wayland client sets the activation token, as received from
- `$DESKTOP_STARTUP_ID`.
+6. Wayland client requests surface activation with the activation token,
+ as received from ``$DESKTOP_STARTUP_ID``.
7. Compositor receives the request, matches ID with the common pool
8. The startup feedback is finished.
-9. Wayland client requests surface activation.
-10. Compositor applies internal policies to allow/deny focus switch.
+9. Compositor applies internal policies to allow/deny focus switch.
Caveats
-------
-- For legacy reasons, the usage of `$DESKTOP_STARTUP_ID` (even if as a
+- For legacy reasons, the usage of ``$DESKTOP_STARTUP_ID`` (even if as a
fallback) should be observed in compositors and clients that are
concerned with X11 interoperation.
- Depending on the X11 startup-notification implementation in use by the
- compositor, the usage of the `_TIME[timestamp]` suffix may be mandatory
+ compositor, the usage of the ``_TIME[timestamp]`` suffix may be mandatory
for its correct behavior in the first scenario, the startup-notification
reference library is one such implementation. Compositors may work
this around by adding a matching suffix to the generated activation tokens.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.21/staging/xdg-activation/xdg-activation-v1.xml
new/wayland-protocols-1.22/staging/xdg-activation/xdg-activation-v1.xml
--- old/wayland-protocols-1.21/staging/xdg-activation/xdg-activation-v1.xml
2021-04-30 16:04:09.000000000 +0200
+++ new/wayland-protocols-1.22/staging/xdg-activation/xdg-activation-v1.xml
2021-09-01 09:24:41.000000000 +0200
@@ -30,8 +30,22 @@
The client that intends to activate another toplevel uses the
xdg_activation_v1.get_activation_token request to get an activation token.
- This token is then passed to the client to be activated through a separate
- band of communication. The client to be activated will then pass the token
+ This token is then forwarded to the client, which is supposed to activate
+ one of its surfaces, through a separate band of communication.
+
+ One established way of doing this is through the XDG_ACTIVATION_TOKEN
+ environment variable of a newly launched child process. The child process
+ should unset the environment variable again right after reading it out in
+ order to avoid propagating it to other child processes.
+
+ Another established way exists for Applications implementing the D-Bus
+ interface org.freedesktop.Application, which should get their token under
+ XDG_ACTIVATION_TOKEN on their platform_data.
+
+ In general activation tokens may be transferred across clients through
+ means not described in this protocol.
+
+ The client to be activated will then pass the token
it received to the xdg_activation_v1.activate request. The compositor can
then use this token to decide how to react to the activation request.
@@ -89,7 +103,7 @@
token and might decide not to follow through with the activation if
it's
considered unwanted.
- Compositors can ignore unknown presentation tokens when an invalid
+ Compositors can ignore unknown activation tokens when an invalid
token is passed.
</description>
<arg name="token" type="string" summary="the activation token of the
initiating client"/>
@@ -120,6 +134,14 @@
Provides information about the seat and serial event that requested the
token.
+ The serial can come from an input or focus event. For instance, if a
+ click triggers the launch of a third-party client, the launcher client
+ should send a set_serial request with the serial and seat from the
+ wl_pointer.button event.
+
+ Some compositors might refuse to activate toplevels when the token
+ doesn't have a valid and recent enough event serial.
+
Must be sent before commit. This information is optional.
</description>
<arg name="serial" type="uint"
@@ -140,11 +162,14 @@
</request>
<request name="set_surface">
- <description summary="specifies the application being activated">
- The requesting client can specify a surface to associate the token
- being created with it.
+ <description summary="specifies the surface requesting activation">
+ This request sets the surface requesting the activation. Note, this is
+ different from the surface that will be activated.
+
+ Some compositors might refuse to activate toplevels when the token
+ doesn't have a requesting surface.
- Must be triggered before commit. This information is optional.
+ Must be sent before commit. This information is optional.
</description>
<arg name="surface" type="object" interface="wl_surface"
summary="the requesting surface"/>
@@ -161,17 +186,6 @@
<description summary="the exported activation token">
The 'done' event contains the unique token of this activation request
and notifies that the provider is done.
-
- Applications will typically receive the token through the
- XDG_ACTIVATION_TOKEN environment variable as set by its launcher, and
- should unset the environment variable right after this request, in
- order to avoid propagating it to child processes.
-
- Applications implementing the D-Bus interface
org.freedesktop.Application
- should get their token under XDG_ACTIVATION_TOKEN on their
platform_data.
-
- Presentation tokens may be transferred across clients through means not
- described in this protocol.
</description>
<arg name="token" type="string" summary="the exported activation token"/>
</event>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.21/tests/build-cxx.cc.in
new/wayland-protocols-1.22/tests/build-cxx.cc.in
--- old/wayland-protocols-1.21/tests/build-cxx.cc.in 2021-03-31
08:35:19.000000000 +0200
+++ new/wayland-protocols-1.22/tests/build-cxx.cc.in 2021-09-01
09:24:41.000000000 +0200
@@ -8,5 +8,7 @@
int
main(int argc, char **argv)
{
+ (void)argc;
+ (void)argv;
return 0;
}
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.21/tests/build-pedantic.c.in
new/wayland-protocols-1.22/tests/build-pedantic.c.in
--- old/wayland-protocols-1.21/tests/build-pedantic.c.in 2021-03-31
08:35:19.000000000 +0200
+++ new/wayland-protocols-1.22/tests/build-pedantic.c.in 2021-09-01
09:24:41.000000000 +0200
@@ -6,5 +6,7 @@
int
main(int argc, char **argv)
{
+ (void)argc;
+ (void)argv;
return 0;
}
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.21/tests/meson.build
new/wayland-protocols-1.22/tests/meson.build
--- old/wayland-protocols-1.21/tests/meson.build 2021-03-31
08:35:19.000000000 +0200
+++ new/wayland-protocols-1.22/tests/meson.build 2021-09-01
09:43:24.000000000 +0200
@@ -11,16 +11,16 @@
protocol_path = join_paths(wayland_protocols_srcdir, protocol_file)
test_name = 'scan-@0@'.format(protocol_file.underscorify())
test(test_name, prog_scan_sh,
- args: protocol_path,
- env: [
- 'SCANNER=@0@'.format(prog_scanner.path()),
- ]
+ args: protocol_path,
+ env: [
+ 'SCANNER=@0@'.format(prog_scanner.path()),
+ ]
)
endforeach
# Check buildability
-add_languages('c', 'cpp')
+add_languages('c', 'cpp', native: true)
replace = find_program('replace.py')
foreach protocol_file : protocol_files
@@ -109,6 +109,7 @@
'-Wall',
'-Werror' ],
install: false,
+ native: true,
)
test(test_name, pedantic_test_executable)
@@ -130,11 +131,13 @@
server_header,
],
link_args: [ '-Wl,--unresolved-symbols=ignore-all' ],
+ 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.21/tests/replace.py
new/wayland-protocols-1.22/tests/replace.py
--- old/wayland-protocols-1.21/tests/replace.py 2021-03-31 08:35:19.000000000
+0200
+++ new/wayland-protocols-1.22/tests/replace.py 2021-09-01 09:24:41.000000000
+0200
@@ -1,4 +1,4 @@
-#!/usr/bin/python3
+#!/usr/bin/env python3
import sys
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.21/unstable/xdg-output/xdg-output-unstable-v1.xml
new/wayland-protocols-1.22/unstable/xdg-output/xdg-output-unstable-v1.xml
--- old/wayland-protocols-1.21/unstable/xdg-output/xdg-output-unstable-v1.xml
2019-11-21 13:53:15.000000000 +0100
+++ new/wayland-protocols-1.22/unstable/xdg-output/xdg-output-unstable-v1.xml
2021-09-01 09:24:41.000000000 +0200
@@ -138,7 +138,7 @@
advertise a logical size of 1920??1080,
- A compositor using a fractional scale of 1.5 will advertise a
- logical size to 2560??1620.
+ logical size of 2560??1440.
For example, for a wl_output mode 1920??1080 and a 90 degree rotation,
the compositor will advertise a logical size of 1080x1920.
