Hello community,
here is the log from the commit of package wayland-protocols for
openSUSE:Factory checked in at 2016-05-26 23:53:26
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/wayland-protocols (Old)
and /work/SRC/openSUSE:Factory/.wayland-protocols.new (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "wayland-protocols"
Changes:
--------
--- /work/SRC/openSUSE:Factory/wayland-protocols/wayland-protocols.changes
2016-03-21 12:45:26.000000000 +0100
+++ /work/SRC/openSUSE:Factory/.wayland-protocols.new/wayland-protocols.changes
2016-05-26 23:53:27.000000000 +0200
@@ -1,0 +2,18 @@
+Mon May 23 22:23:27 UTC 2016 - zai...@opensuse.org
+
+- Update to version 1.4:
+ * This release include one new stable protocol extension:
+ viewporter.
+ * The viewporter porter has previously been known as "wl_scaler"
+ and enables a client to crop and scale a surface server side.
+ Clients and compositors previously implementing support for
+ wl_scaler should adapt accordingly. See the corresponding XML
+ file for details.
+ * Other changes included in this release are various grammatical
+ corrections to the presentation-time, tablet, relative-pointer,
+ pointer-constraints, linux-dmabuf, input-method and
+ fullscreen-shell protocols.
+ * It's now also possible to use autotools build files to install
+ on platforms where the host CPU is not recognized.
+
+-------------------------------------------------------------------
Old:
----
wayland-protocols-1.3.tar.xz
wayland-protocols-1.3.tar.xz.sig
New:
----
wayland-protocols-1.4.tar.xz
wayland-protocols-1.4.tar.xz.sig
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ wayland-protocols.spec ++++++
--- /var/tmp/diff_new_pack.0pHGlt/_old 2016-05-26 23:53:28.000000000 +0200
+++ /var/tmp/diff_new_pack.0pHGlt/_new 2016-05-26 23:53:28.000000000 +0200
@@ -18,7 +18,7 @@
Name: wayland-protocols
-Version: 1.3
+Version: 1.4
Release: 0
Summary: Wayland protocols that adds functionality not available in the
core protocol
License: MIT
++++++ wayland-protocols-1.3.tar.xz -> wayland-protocols-1.4.tar.xz ++++++
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.3/Makefile.am
new/wayland-protocols-1.4/Makefile.am
--- old/wayland-protocols-1.3/Makefile.am 2016-03-09 08:48:42.000000000
+0100
+++ new/wayland-protocols-1.4/Makefile.am 2016-05-23 05:32:30.000000000
+0200
@@ -12,6 +12,7 @@
stable_protocols =
\
stable/presentation-time/presentation-time.xml
\
+ stable/viewporter/viewporter.xml
\
$(NULL)
nobase_dist_pkgdata_DATA =
\
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.3/Makefile.in
new/wayland-protocols-1.4/Makefile.in
--- old/wayland-protocols-1.3/Makefile.in 2016-03-10 08:03:21.000000000
+0100
+++ new/wayland-protocols-1.4/Makefile.in 2016-05-23 05:32:43.000000000
+0200
@@ -86,8 +86,6 @@
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
-build_triplet = @build@
-host_triplet = @host@
TESTS = $(am__EXEEXT_1) $(am__EXEEXT_2)
subdir = .
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
@@ -321,7 +319,8 @@
unstable/relative-pointer/relative-pointer-unstable-v1.xml \
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml \
unstable/tablet/tablet-unstable-v1.xml
-am__EXEEXT_2 = stable/presentation-time/presentation-time.xml
+am__EXEEXT_2 = stable/presentation-time/presentation-time.xml \
+ stable/viewporter/viewporter.xml
TEST_SUITE_LOG = test-suite.log
am__test_logs1 = $(TESTS:=.log)
TEST_LOGS = $(am__test_logs1:.xml.log=.log)
@@ -406,22 +405,14 @@
am__tar = @am__tar@
am__untar = @am__untar@
bindir = @bindir@
-build = @build@
build_alias = @build_alias@
-build_cpu = @build_cpu@
-build_os = @build_os@
-build_vendor = @build_vendor@
builddir = @builddir@
datadir = @datadir@
datarootdir = @datarootdir@
docdir = @docdir@
dvidir = @dvidir@
exec_prefix = @exec_prefix@
-host = @host@
host_alias = @host_alias@
-host_cpu = @host_cpu@
-host_os = @host_os@
-host_vendor = @host_vendor@
htmldir = @htmldir@
includedir = @includedir@
infodir = @infodir@
@@ -461,6 +452,7 @@
stable_protocols = \
stable/presentation-time/presentation-time.xml
\
+ stable/viewporter/viewporter.xml
\
$(NULL)
nobase_dist_pkgdata_DATA = \
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.3/README
new/wayland-protocols-1.4/README
--- old/wayland-protocols-1.3/README 2015-11-25 07:49:58.000000000 +0100
+++ new/wayland-protocols-1.4/README 2016-05-23 05:32:30.000000000 +0200
@@ -1,9 +1,9 @@
Wayland protocols
-----------------
-wayland-protocols contains Wayland protocols that adds functionality not
-available in the Wayland core protocol. Such protocols either adds
-completely new functionality, or extends the functionality of some other
+wayland-protocols contains Wayland protocols that add functionality not
+available in the Wayland core protocol. Such protocols either add
+completely new functionality, or extend the functionality of some other
protocol either in Wayland core, or some other protocol in
wayland-protocols.
@@ -29,7 +29,7 @@
other protocol, or declared undesirable for some other reason. No more
changes will be made to a deprecated protocol.
-Depending on which of the above state the protocol is in, the protocol
+Depending on which of the above states the protocol is in, the protocol
is placed within the toplevel directory containing the protocols with the
same state. Stable protocols are placed in the +stable/+ directory,
unstable protocols are placed in the +unstable/+ directory, and
@@ -72,8 +72,8 @@
Unstable protocols have a special naming convention in order to make it
possible to make discoverable backward incompatible changes.
-An unstable protocol has at least two versions; the major version which
-represents backward incompatible changes, and the minor versions which
+An unstable protocol has at least two versions: the major version, which
+represents backward incompatible changes, and the minor version, which
represents backward compatible changes to the interfaces in the protocol.
The major version is part of the XML file name, the protocol name in the
@@ -100,7 +100,7 @@
incompatible changes are needed. Such a change needs to be represented
in the major and minor versions of the protocol.
-Assuming a backward incompatible change is needed, the procedure how to
+Assuming a backward incompatible change is needed, the procedure for how to
do so is the following:
. Make a copy of the XML file with the major version increased by +1+.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.3/configure
new/wayland-protocols-1.4/configure
--- old/wayland-protocols-1.3/configure 2016-03-10 08:03:22.000000000 +0100
+++ new/wayland-protocols-1.4/configure 2016-05-23 05:32:43.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.3.
+# Generated by GNU Autoconf 2.69 for wayland-protocols 1.4.
#
# 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.3'
-PACKAGE_STRING='wayland-protocols 1.3'
+PACKAGE_VERSION='1.4'
+PACKAGE_STRING='wayland-protocols 1.4'
PACKAGE_BUGREPORT='https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=wayland&version=unspecified'
PACKAGE_URL='http://wayland.freedesktop.org/'
@@ -621,14 +621,6 @@
PKG_CONFIG_PATH
PKG_CONFIG
wayland_scanner
-host_os
-host_vendor
-host_cpu
-host
-build_os
-build_vendor
-build_cpu
-build
WAYLAND_PROTOCOLS_VERSION
target_alias
host_alias
@@ -1223,7 +1215,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.3 to adapt to many kinds of
systems.
+\`configure' configures wayland-protocols 1.4 to adapt to many kinds of
systems.
Usage: $0 [OPTION]... [VAR=VALUE]...
@@ -1285,16 +1277,12 @@
--program-prefix=PREFIX prepend PREFIX to installed program names
--program-suffix=SUFFIX append SUFFIX to installed program names
--program-transform-name=PROGRAM run sed PROGRAM on installed program names
-
-System types:
- --build=BUILD configure for building on BUILD [guessed]
- --host=HOST cross-compile to build programs to run on HOST [BUILD]
_ACEOF
fi
if test -n "$ac_init_help"; then
case $ac_init_help in
- short | recursive ) echo "Configuration of wayland-protocols 1.3:";;
+ short | recursive ) echo "Configuration of wayland-protocols 1.4:";;
esac
cat <<\_ACEOF
@@ -1392,7 +1380,7 @@
test -n "$ac_init_help" && exit $ac_status
if $ac_init_version; then
cat <<\_ACEOF
-wayland-protocols configure 1.3
+wayland-protocols configure 1.4
generated by GNU Autoconf 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
@@ -1409,7 +1397,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.3, which was
+It was created by wayland-protocols $as_me 1.4, which was
generated by GNU Autoconf 2.69. Invocation command line was
$ $0 $@
@@ -1760,109 +1748,7 @@
-WAYLAND_PROTOCOLS_VERSION=1.3
-
-
-ac_aux_dir=
-for ac_dir in "$srcdir" "$srcdir/.." "$srcdir/../.."; do
- if test -f "$ac_dir/install-sh"; then
- ac_aux_dir=$ac_dir
- ac_install_sh="$ac_aux_dir/install-sh -c"
- break
- elif test -f "$ac_dir/install.sh"; then
- ac_aux_dir=$ac_dir
- ac_install_sh="$ac_aux_dir/install.sh -c"
- break
- elif test -f "$ac_dir/shtool"; then
- ac_aux_dir=$ac_dir
- ac_install_sh="$ac_aux_dir/shtool install -c"
- break
- fi
-done
-if test -z "$ac_aux_dir"; then
- as_fn_error $? "cannot find install-sh, install.sh, or shtool in \"$srcdir\"
\"$srcdir/..\" \"$srcdir/../..\"" "$LINENO" 5
-fi
-
-# These three variables are undocumented and unsupported,
-# and are intended to be withdrawn in a future Autoconf release.
-# They can cause serious problems if a builder's source tree is in a directory
-# whose full name contains unusual characters.
-ac_config_guess="$SHELL $ac_aux_dir/config.guess" # Please don't use this var.
-ac_config_sub="$SHELL $ac_aux_dir/config.sub" # Please don't use this var.
-ac_configure="$SHELL $ac_aux_dir/configure" # Please don't use this var.
-
-
-# Make sure we can run config.sub.
-$SHELL "$ac_aux_dir/config.sub" sun4 >/dev/null 2>&1 ||
- as_fn_error $? "cannot run $SHELL $ac_aux_dir/config.sub" "$LINENO" 5
-
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking build system type" >&5
-$as_echo_n "checking build system type... " >&6; }
-if ${ac_cv_build+:} false; then :
- $as_echo_n "(cached) " >&6
-else
- ac_build_alias=$build_alias
-test "x$ac_build_alias" = x &&
- ac_build_alias=`$SHELL "$ac_aux_dir/config.guess"`
-test "x$ac_build_alias" = x &&
- as_fn_error $? "cannot guess build type; you must specify one" "$LINENO" 5
-ac_cv_build=`$SHELL "$ac_aux_dir/config.sub" $ac_build_alias` ||
- as_fn_error $? "$SHELL $ac_aux_dir/config.sub $ac_build_alias failed"
"$LINENO" 5
-
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_build" >&5
-$as_echo "$ac_cv_build" >&6; }
-case $ac_cv_build in
-*-*-*) ;;
-*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5;;
-esac
-build=$ac_cv_build
-ac_save_IFS=$IFS; IFS='-'
-set x $ac_cv_build
-shift
-build_cpu=$1
-build_vendor=$2
-shift; shift
-# Remember, the first character of IFS is used to create $*,
-# except with old shells:
-build_os=$*
-IFS=$ac_save_IFS
-case $build_os in *\ *) build_os=`echo "$build_os" | sed 's/ /-/g'`;; esac
-
-
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking host system type" >&5
-$as_echo_n "checking host system type... " >&6; }
-if ${ac_cv_host+:} false; then :
- $as_echo_n "(cached) " >&6
-else
- if test "x$host_alias" = x; then
- ac_cv_host=$ac_cv_build
-else
- ac_cv_host=`$SHELL "$ac_aux_dir/config.sub" $host_alias` ||
- as_fn_error $? "$SHELL $ac_aux_dir/config.sub $host_alias failed"
"$LINENO" 5
-fi
-
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_host" >&5
-$as_echo "$ac_cv_host" >&6; }
-case $ac_cv_host in
-*-*-*) ;;
-*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5;;
-esac
-host=$ac_cv_host
-ac_save_IFS=$IFS; IFS='-'
-set x $ac_cv_host
-shift
-host_cpu=$1
-host_vendor=$2
-shift; shift
-# Remember, the first character of IFS is used to create $*,
-# except with old shells:
-host_os=$*
-IFS=$ac_save_IFS
-case $host_os in *\ *) host_os=`echo "$host_os" | sed 's/ /-/g'`;; esac
-
-
+WAYLAND_PROTOCOLS_VERSION=1.4
@@ -1907,7 +1793,7 @@
if test x$wayland_scanner = x; then
- if test x$host = x$build; then
+ if test "x$cross_compiling" != "xyes"; then
@@ -2128,6 +2014,35 @@
am__api_version='1.15'
+ac_aux_dir=
+for ac_dir in "$srcdir" "$srcdir/.." "$srcdir/../.."; do
+ if test -f "$ac_dir/install-sh"; then
+ ac_aux_dir=$ac_dir
+ ac_install_sh="$ac_aux_dir/install-sh -c"
+ break
+ elif test -f "$ac_dir/install.sh"; then
+ ac_aux_dir=$ac_dir
+ ac_install_sh="$ac_aux_dir/install.sh -c"
+ break
+ elif test -f "$ac_dir/shtool"; then
+ ac_aux_dir=$ac_dir
+ ac_install_sh="$ac_aux_dir/shtool install -c"
+ break
+ fi
+done
+if test -z "$ac_aux_dir"; then
+ as_fn_error $? "cannot find install-sh, install.sh, or shtool in \"$srcdir\"
\"$srcdir/..\" \"$srcdir/../..\"" "$LINENO" 5
+fi
+
+# These three variables are undocumented and unsupported,
+# and are intended to be withdrawn in a future Autoconf release.
+# They can cause serious problems if a builder's source tree is in a directory
+# whose full name contains unusual characters.
+ac_config_guess="$SHELL $ac_aux_dir/config.guess" # Please don't use this var.
+ac_config_sub="$SHELL $ac_aux_dir/config.sub" # Please don't use this var.
+ac_configure="$SHELL $ac_aux_dir/configure" # Please don't use this var.
+
+
# Find a good install program. We prefer a C program (faster),
# so one script is as good as another. But avoid the broken or
# incompatible versions:
@@ -2612,7 +2527,7 @@
# Define the identity of the package.
PACKAGE='wayland-protocols'
- VERSION='1.3'
+ VERSION='1.4'
cat >>confdefs.h <<_ACEOF
@@ -3315,7 +3230,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.3, which was
+This file was extended by wayland-protocols $as_me 1.4, which was
generated by GNU Autoconf 2.69. Invocation command line was
CONFIG_FILES = $CONFIG_FILES
@@ -3369,7 +3284,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.3
+wayland-protocols config.status 1.4
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.3/configure.ac
new/wayland-protocols-1.4/configure.ac
--- old/wayland-protocols-1.3/configure.ac 2016-03-10 08:02:15.000000000
+0100
+++ new/wayland-protocols-1.4/configure.ac 2016-05-23 05:32:40.000000000
+0200
@@ -1,7 +1,7 @@
AC_PREREQ([2.64])
m4_define([wayland_protocols_major_version], [1])
-m4_define([wayland_protocols_minor_version], [3])
+m4_define([wayland_protocols_minor_version], [4])
m4_define([wayland_protocols_version],
[wayland_protocols_major_version.wayland_protocols_minor_version])
@@ -15,13 +15,10 @@
AC_SUBST([WAYLAND_PROTOCOLS_VERSION], [wayland_protocols_version])
-AC_CANONICAL_HOST
-AC_CANONICAL_BUILD
-
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$host = x$build; 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
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.3/stable/presentation-time/presentation-time.xml
new/wayland-protocols-1.4/stable/presentation-time/presentation-time.xml
--- old/wayland-protocols-1.3/stable/presentation-time/presentation-time.xml
2016-03-05 05:05:42.000000000 +0100
+++ new/wayland-protocols-1.4/stable/presentation-time/presentation-time.xml
2016-05-23 05:32:30.000000000 +0200
@@ -33,14 +33,13 @@
The main feature of this interface is accurate presentation
timing feedback to ensure smooth video playback while maintaining
audio/video synchronization. Some features use the concept of a
- presentation clock, which is defined in presentation.clock_id
- event.
+ presentation clock, which is defined in the
+ presentation.clock_id event.
- Request 'feedback' can be regarded as an additional wl_surface
- method. It is part of the double-buffered surface state update
- mechanism, where other requests first set up the state and then
- wl_surface.commit atomically applies the state into use. In
- other words, wl_surface.commit submits a content update.
+ A content update for a wl_surface is submitted by a
+ wl_surface.commit request. Request 'feedback' associates with
+ the wl_surface.commit and provides feedback on the content
+ update, particularly the final realized presentation time.
<!-- Completing presentation -->
@@ -65,9 +64,9 @@
<request name="destroy" type="destructor">
<description summary="unbind from the presentation interface">
- Informs the server that the client will not be using this
- protocol object anymore. This does not affect any existing
- objects created by this interface.
+ Informs the server that the client will no longer be using
+ this protocol object. Existing objects created by this object
+ are not affected.
</description>
</request>
@@ -79,7 +78,7 @@
multiple presentation_feedback objects are created for the same
submission, they will all deliver the same information.
- For details on what information is returned, see
+ For details on what information is returned, see the
presentation_feedback interface.
</description>
@@ -99,18 +98,10 @@
presentation interface. The presentation clock does not change
during the lifetime of the client connection.
- The clock identifier is platform dependent. Clients must be
- able to query the current clock value directly, not by asking
- the compositor.
-
- On Linux/glibc, the identifier value is one of the clockid_t
- values accepted by clock_gettime(). clock_gettime() is defined
- by POSIX.1-2001.
-
- Compositors should prefer a clock which does not jump and is
- not slewed e.g. by NTP. The absolute value of the clock is
- irrelevant. Precision of one millisecond or better is
- recommended.
+ The clock identifier is platform dependent. On Linux/glibc,
+ the identifier value is one of the clockid_t values accepted
+ by clock_gettime(). clock_gettime() is defined by
+ POSIX.1-2001.
Timestamps in this clock domain are expressed as tv_sec_hi,
tv_sec_lo, tv_nsec triples, each component being an unsigned
@@ -122,6 +113,12 @@
Note that clock_id applies only to the presentation clock,
and implies nothing about e.g. the timestamps used in the
Wayland core protocol input events.
+
+ Compositors should prefer a clock which does not jump and is
+ not slewed e.g. by NTP. The absolute value of the clock is
+ irrelevant. Precision of one millisecond or better is
+ recommended. Clients must be able to query the current clock
+ value directly, not by asking the compositor.
</description>
<arg name="clk_id" type="uint" summary="platform clock identifier"/>
@@ -140,7 +137,7 @@
update because it was superseded or its surface destroyed,
and the content update is discarded.
- Once a presentation_feedback object has delivered an 'presented'
+ Once a presentation_feedback object has delivered a 'presented'
or 'discarded' event it is automatically destroyed.
</description>
@@ -225,13 +222,17 @@
chose. Having a stable presentation output association helps
clients predict future output refreshes (vblank).
- Argument 'refresh' gives the compositor's prediction of how
+ The 'refresh' argument gives the compositor's prediction of how
many nanoseconds after tv_sec, tv_nsec the very next output
refresh may occur. This is to further aid clients in
predicting future refreshes, i.e., estimating the timestamps
targeting the next few vblanks. If such prediction cannot
usefully be done, the argument is zero.
+ If the output does not have a constant refresh rate, explicit
+ video mode switches excluded, then the refresh argument must
+ be zero.
+
The 64-bit value combined from seq_hi and seq_lo is the value
of the output's vertical retrace counter when the content
update was first scanned out to the display. This value must
@@ -240,10 +241,6 @@
path has a non-zero latency, the time instant specified by
this counter may differ from the timestamp's.
- If the output does not have a constant refresh rate, explicit
- video mode switches excluded, then the refresh argument must
- be zero.
-
If the output does not have a concept of vertical retrace or a
refresh cycle, or the output device is self-refreshing without
a way to query the refresh count, then the arguments seq_hi
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/wayland-protocols-1.3/stable/viewporter/README
new/wayland-protocols-1.4/stable/viewporter/README
--- old/wayland-protocols-1.3/stable/viewporter/README 1970-01-01
01:00:00.000000000 +0100
+++ new/wayland-protocols-1.4/stable/viewporter/README 2016-05-23
05:32:30.000000000 +0200
@@ -0,0 +1,7 @@
+Viewporter: cropping and scaling extension for surface contents
+
+Previously known as wl_scaler.
+
+Maintainers:
+Pekka Paalanen <pekka.paala...@collabora.co.uk>
+
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.3/stable/viewporter/viewporter.xml
new/wayland-protocols-1.4/stable/viewporter/viewporter.xml
--- old/wayland-protocols-1.3/stable/viewporter/viewporter.xml 1970-01-01
01:00:00.000000000 +0100
+++ new/wayland-protocols-1.4/stable/viewporter/viewporter.xml 2016-05-23
05:32:30.000000000 +0200
@@ -0,0 +1,189 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="viewporter">
+
+ <copyright>
+ Copyright © 2013-2016 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.
+ </copyright>
+
+ <interface name="wp_viewporter" version="1">
+ <description summary="surface cropping and scaling">
+ The global interface exposing surface cropping and scaling
+ capabilities is used to instantiate an interface extension for a
+ wl_surface object. This extended interface will then allow
+ cropping and scaling the surface contents, effectively
+ disconnecting the direct relationship between the buffer and the
+ surface size.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="unbind from the cropping and scaling interface">
+ Informs the server that the client will not be using this
+ protocol object anymore. This does not affect any other objects,
+ wp_viewport objects included.
+ </description>
+ </request>
+
+ <enum name="error">
+ <entry name="viewport_exists" value="0"
+ summary="the surface already has a viewport object associated"/>
+ </enum>
+
+ <request name="get_viewport">
+ <description summary="extend surface interface for crop and scale">
+ Instantiate an interface extension for the given wl_surface to
+ crop and scale its content. If the given wl_surface already has
+ a wp_viewport object associated, the viewport_exists
+ protocol error is raised.
+ </description>
+
+ <arg name="id" type="new_id" interface="wp_viewport"
+ summary="the new viewport interface id"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface"/>
+ </request>
+ </interface>
+
+ <interface name="wp_viewport" version="1">
+ <description summary="crop and scale interface to a wl_surface">
+ An additional interface to a wl_surface object, which allows the
+ client to specify the cropping and scaling of the surface
+ contents.
+
+ This interface works with two concepts: the source rectangle (src_x,
+ src_y, src_width, src_height), and the destination size (dst_width,
+ dst_height). The contents of the source rectangle are scaled to the
+ destination size, and content outside the source rectangle is ignored.
+ This state is double-buffered, and is applied on the next
+ wl_surface.commit.
+
+ The two parts of crop and scale state are independent: the source
+ rectangle, and the destination size. Initially both are unset, that
+ is, no scaling is applied. The whole of the current wl_buffer is
+ used as the source, and the surface size is as defined in
+ wl_surface.attach.
+
+ If the destination size is set, it causes the surface size to become
+ dst_width, dst_height. The source (rectangle) is scaled to exactly
+ this size. This overrides whatever the attached wl_buffer size is,
+ unless the wl_buffer is NULL. If the wl_buffer is NULL, the surface
+ has no content and therefore no size. Otherwise, the size is always
+ at least 1x1 in surface local coordinates.
+
+ If the source rectangle is set, it defines what area of the wl_buffer is
+ taken as the source. If the source rectangle is set and the destination
+ size is not set, then src_width and src_height must be integers, and the
+ surface size becomes the source rectangle size. This results in cropping
+ without scaling. If src_width or src_height are not integers and
+ destination size is not set, the bad_size protocol error is raised when
+ the surface state is applied.
+
+ The coordinate transformations from buffer pixel coordinates up to
+ the surface-local coordinates happen in the following order:
+ 1. buffer_transform (wl_surface.set_buffer_transform)
+ 2. buffer_scale (wl_surface.set_buffer_scale)
+ 3. crop and scale (wp_viewport.set*)
+ This means, that the source rectangle coordinates of crop and scale
+ are given in the coordinates after the buffer transform and scale,
+ i.e. in the coordinates that would be the surface-local coordinates
+ if the crop and scale was not applied.
+
+ If src_x or src_y are negative, the bad_value protocol error is raised.
+ Otherwise, if the source rectangle is partially or completely outside of
+ the non-NULL wl_buffer, then the out_of_buffer protocol error is raised
+ when the surface state is applied. A NULL wl_buffer does not raise the
+ out_of_buffer error.
+
+ The x, y arguments of wl_surface.attach are applied as normal to
+ the surface. They indicate how many pixels to remove from the
+ surface size from the left and the top. In other words, they are
+ still in the surface-local coordinate system, just like dst_width
+ and dst_height are.
+
+ If the wl_surface associated with the wp_viewport is destroyed,
+ all wp_viewport requests except 'destroy' raise the protocol error
+ no_surface.
+
+ If the wp_viewport object is destroyed, the crop and scale
+ state is removed from the wl_surface. The change will be applied
+ on the next wl_surface.commit.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="remove scaling and cropping from the surface">
+ The associated wl_surface's crop and scale state is removed.
+ The change is applied on the next wl_surface.commit.
+ </description>
+ </request>
+
+ <enum name="error">
+ <entry name="bad_value" value="0"
+ summary="negative or zero values in width or height"/>
+ <entry name="bad_size" value="1"
+ summary="destination size is not integer"/>
+ <entry name="out_of_buffer" value="2"
+ summary="source rectangle extends outside of the content area"/>
+ <entry name="no_surface" value="3"
+ summary="the wl_surface was destroyed"/>
+ </enum>
+
+ <request name="set_source">
+ <description summary="set the source rectangle for cropping">
+ Set the source rectangle of the associated wl_surface. See
+ wp_viewport for the description, and relation to the wl_buffer
+ size.
+
+ If all of x, y, width and height are -1.0, the source rectangle is
+ unset instead. Any other set of values where width or height are zero
+ or negative, or x or y are negative, raise the bad_value protocol
+ error.
+
+ The crop and scale state is double-buffered state, and will be
+ applied on the next wl_surface.commit.
+ </description>
+
+ <arg name="x" type="fixed" summary="source rectangle x"/>
+ <arg name="y" type="fixed" summary="source rectangle y"/>
+ <arg name="width" type="fixed" summary="source rectangle width"/>
+ <arg name="height" type="fixed" summary="source rectangle height"/>
+ </request>
+
+ <request name="set_destination">
+ <description summary="set the surface size for scaling">
+ Set the destination size of the associated wl_surface. See
+ wp_viewport for the description, and relation to the wl_buffer
+ size.
+
+ If width is -1 and height is -1, the destination size is unset
+ instead. Any other pair of values for width and height that
+ contains zero or negative values raises the bad_value protocol
+ error.
+
+ The crop and scale state is double-buffered state, and will be
+ applied on the next wl_surface.commit.
+ </description>
+
+ <arg name="width" type="int" summary="surface width"/>
+ <arg name="height" type="int" summary="surface height"/>
+ </request>
+ </interface>
+
+</protocol>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.3/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
new/wayland-protocols-1.4/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
---
old/wayland-protocols-1.3/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
2015-11-17 04:46:57.000000000 +0100
+++
new/wayland-protocols-1.4/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml
2016-05-23 05:32:30.000000000 +0200
@@ -1,6 +1,8 @@
+<?xml version="1.0" encoding="UTF-8"?>
<protocol name="fullscreen_shell_unstable_v1">
+
<interface name="zwp_fullscreen_shell_v1" version="1">
- <description summary="Displays a single surface per output">
+ <description summary="displays a single surface per output">
Displays a single surface per output.
This interface provides a mechanism for a single client to display
@@ -14,7 +16,7 @@
details about scaling and mode switches.
The client can have at most one surface per output at any time.
- Requesting a surface be presented on an output that already has a
+ Requesting a surface to be presented on an output that already has a
surface replaces the previously presented surface. Presenting a null
surface removes its content and effectively disables the output.
Exactly what happens when an output is "disabled" is
@@ -38,7 +40,7 @@
<request name="release" type="destructor">
<description summary="release the wl_fullscreen_shell interface">
- Release the binding from the wl_fullscreen_shell interface
+ Release the binding from the wl_fullscreen_shell interface.
This destroys the server-side object and frees this binding. If
the client binds to wl_fullscreen_shell multiple times, it may wish
@@ -52,7 +54,7 @@
are advertised one-at-a-time when the wl_fullscreen_shell interface is
bound. See the wl_fullscreen_shell.capability event for more details.
- ARBITRARY_MODE:
+ ARBITRARY_MODES:
This is a hint to the client that indicates that the compositor is
capable of setting practically any mode on its outputs. If this
capability is provided, wl_fullscreen_shell.present_surface_for_mode
@@ -85,7 +87,7 @@
wl_display.sync request immediately after binding to ensure that they
receive all the capability events.
</description>
- <arg name="capabilty" type="uint"/>
+ <arg name="capability" type="uint"/>
</event>
<enum name="present_method">
@@ -174,7 +176,7 @@
<enum name="error">
<description summary="wl_fullscreen_shell error values">
- These errors can be emitted in response to wl_fullscreen_shell requests
+ These errors can be emitted in response to wl_fullscreen_shell requests.
</description>
<entry name="invalid_method" value="0" summary="present_method is not
known"/>
</enum>
@@ -191,16 +193,18 @@
wl_fullscreen_shell_mode_feedback object.
</description>
</event>
+
<event name="mode_failed">
<description summary="mode switch failed">
This event indicates that the attempted mode switch operation
- failed. This may be because the requested output mode is not
+ failed. This may be because the requested output mode is not
possible or it may mean that the compositor does not want to allow it.
Upon receiving this event, the client should destroy the
wl_fullscreen_shell_mode_feedback object.
</description>
</event>
+
<event name="present_cancelled">
<description summary="mode switch cancelled">
This event indicates that the attempted mode switch operation was
@@ -212,4 +216,5 @@
</description>
</event>
</interface>
+
</protocol>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.3/unstable/input-method/input-method-unstable-v1.xml
new/wayland-protocols-1.4/unstable/input-method/input-method-unstable-v1.xml
---
old/wayland-protocols-1.3/unstable/input-method/input-method-unstable-v1.xml
2015-11-17 04:46:57.000000000 +0100
+++
new/wayland-protocols-1.4/unstable/input-method/input-method-unstable-v1.xml
2016-05-23 05:32:30.000000000 +0200
@@ -26,7 +26,7 @@
<interface name="zwp_input_method_context_v1" version="1">
<description summary="input method context">
- Corresponds to a text input on input method side. An input method context
+ Corresponds to a text input on the input method side. An input method
context
is created on text input activation on the input method side. It allows
to
receive information about the text input from the application via events.
Input method contexts do not keep state after deactivation and should be
@@ -73,11 +73,11 @@
<description summary="pre-edit string">
Send the pre-edit string text to the application text input.
- The commit text can be used to replace the preedit text on reset (for
+ The commit text can be used to replace the pre-edit text on reset (for
example on unfocus).
- Also previously sent preedit_style and preedit_cursor requests are
- processed bt the text_input also.
+ Previously sent preedit_style and preedit_cursor requests are also
+ processed by the text_input.
</description>
<arg name="serial" type="uint" summary="serial of the latest known text
input state"/>
<arg name="text" type="string"/>
@@ -91,7 +91,7 @@
the composing text (as byte offset). Multiple styles can
be applied to a composing text.
- This request should be sent before sending preedit_string request.
+ This request should be sent before sending a preedit_string request.
</description>
<arg name="index" type="uint"/>
<arg name="length" type="uint"/>
@@ -105,15 +105,15 @@
When index is negative no cursor should be displayed.
- This request should be sent before sending preedit_string request.
+ This request should be sent before sending a preedit_string request.
</description>
<arg name="index" type="int"/>
</request>
<request name="delete_surrounding_text">
<description summary="delete text">
- This request will be handled on text_input side as part of a directly
- following commit_string request.
+ This request will be handled on the text_input side directly following
+ a commit_string request.
</description>
<arg name="index" type="int"/>
<arg name="length" type="uint"/>
@@ -122,14 +122,15 @@
<request name="cursor_position">
<description summary="set cursor to a new position">
Sets the cursor and anchor to a new position. Index is the new cursor
- position in bytes (when >= 0 relative to the end of inserted text
- else relative to beginning of inserted text). Anchor is the new anchor
- position in bytes (when >= 0 relative to the end of inserted text, else
- relative to beginning of inserted text). When there should be no
- selected text anchor should be the same as index.
+ position in bytes (when >= 0 relative to the end of inserted text,
+ otherwise relative to the beginning of the inserted text). Anchor is
+ the new anchor position in bytes (when >= 0 relative to the end of the
+ inserted text, otherwise relative to the beginning of the inserted
+ text). When there should be no selected text, anchor should be the same
+ as index.
- This request will be handled on text_input side as part of a directly
- following commit_string request.
+ This request will be handled on the text_input side directly following
+ a commit_string request.
</description>
<arg name="index" type="int"/>
<arg name="anchor" type="int"/>
@@ -143,7 +144,7 @@
<description summary="keysym">
Notify when a key event was sent. Key events should not be used for
normal text input operations, which should be done with commit_string,
- delete_surrounfing_text, etc. The key event follows the wl_keyboard key
+ delete_surrounding_text, etc. The key event follows the wl_keyboard key
event convention. Sym is a XKB keysym, state a wl_keyboard key_state.
</description>
<arg name="serial" type="uint" summary="serial of the latest known text
input state"/>
@@ -184,7 +185,7 @@
<description summary="forward modifiers event">
Should be used when filtering key events with grab_keyboard.
- When the wl_keyboard::modifiers event should be also send to the
+ When the wl_keyboard::modifiers event should also be sent to the
client, forward it with this request. The arguments should be the ones
from the wl_keyboard::modifiers event.
</description>
@@ -199,6 +200,7 @@
<arg name="serial" type="uint" summary="serial of the latest known text
input state"/>
<arg name="language" type="string"/>
</request>
+
<request name="text_direction">
<arg name="serial" type="uint" summary="serial of the latest known text
input state"/>
<arg name="direction" type="uint"/>
@@ -241,7 +243,7 @@
<interface name="zwp_input_method_v1" version="1">
<description summary="input method">
- An input method object is responsible to compose text in response to
+ An input method object is responsible for composing text in response to
input from hardware or virtual keyboards. There is one input method
object per seat. On activate there is a new input method context object
created which allows the input method to communicate with the text input.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.3/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
new/wayland-protocols-1.4/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
---
old/wayland-protocols-1.3/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
2015-11-17 04:46:57.000000000 +0100
+++
new/wayland-protocols-1.4/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
2016-05-23 05:32:30.000000000 +0200
@@ -56,11 +56,11 @@
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 zwp_linux_dmabuf_v1.create_params
+ 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, 'create' request is issued. The server
- will reply with either 'created' event which provides the final
- wl_buffer or 'failed' event saying that it cannot use the dmabufs
+ the 'add' request. Finally, a 'create' request is issued. The server
+ will reply with either a 'created' event which provides the final
+ wl_buffer or a 'failed' event saying that it cannot use the dmabufs
provided.
Warning! The protocol described in this file is experimental and
@@ -84,7 +84,7 @@
<description summary="create a temporary object for buffer parameters">
This temporary object is used to collect multiple dmabuf handles into
a single batch to create a wl_buffer. It can only be used once and
- should be destroyed after an 'created' or 'failed' event has been
+ should be destroyed after a 'created' or 'failed' event has been
received.
</description>
<arg name="params_id" type="new_id"
interface="zwp_linux_buffer_params_v1"
@@ -95,7 +95,7 @@
<description summary="supported buffer format">
This event advertises one buffer format that the server supports.
All the supported formats are advertised once when the client
- binds to this interface. A roundtrip after binding guarantees,
+ binds to this interface. A roundtrip after binding guarantees
that the client has received all supported formats.
For the definition of the format codes, see create request.
@@ -104,7 +104,6 @@
</description>
<arg name="format" type="uint" summary="DRM_FORMAT code"/>
</event>
-
</interface>
<interface name="zwp_linux_buffer_params_v1" version="1">
@@ -116,7 +115,7 @@
Single-planar formats only require one dmabuf, however
multi-planar formats may require more than one dmabuf. For all
- formats, 'add' request must be called once per plane (even if the
+ formats, an 'add' request must be called once per plane (even if the
underlying dmabuf fd is identical).
You must use consecutive plane indices ('plane_idx' argument for 'add')
@@ -244,7 +243,7 @@
This request can be sent only once in the object's lifetime, after
which the only legal request is destroy. This object should be
- destroyed after issuing 'create' request. Attempting to use this
+ destroyed after issuing a 'create' request. Attempting to use this
object after issuing 'create' raises ALREADY_USED protocol error.
It is not mandatory to issue 'create'. If a client wants to
@@ -278,7 +277,6 @@
zlinux_buffer_params object.
</description>
</event>
-
</interface>
</protocol>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.3/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
new/wayland-protocols-1.4/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
---
old/wayland-protocols-1.3/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
2016-03-05 05:05:42.000000000 +0100
+++
new/wayland-protocols-1.4/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
2016-05-23 05:32:30.000000000 +0200
@@ -25,12 +25,12 @@
DEALINGS IN THE SOFTWARE.
</copyright>
- <description summary="Protocol for constraining pointer motions">
+ <description summary="protocol for constraining pointer motions">
This protocol specifies a set of interfaces used for adding constraints to
the motion of a pointer. Possible constraints include confining pointer
motions to a given region, or locking it to its current position.
- In order to contrain the pointer, a client must first bind the global
+ In order to constrain the pointer, a client must first bind the global
interface "wp_pointer_constraints" which, if a compositor supports pointer
constraints, is exposed by the registry. Using the bound global object, the
client uses the request that corresponds to the type of constraint it wants
@@ -38,9 +38,9 @@
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. Backward
+ together with the corresponding interface version bump. Backward
incompatible changes are done by bumping the version number in the protocol
- and interface names and resetting the interface version. Once the protocol
+ and interface names and resetting the interface version. Once the protocol
is to be declared stable, the 'z' prefix and the version number in the
protocol and interface names are removed and the interface version number
is
reset.
@@ -49,7 +49,7 @@
<interface name="zwp_pointer_constraints_v1" version="1">
<description summary="constrain the movement of a pointer">
The global interface exposing pointer constraining functionality. It
- exposes two requests; lock_pointer for locking the pointer to its
+ exposes two requests: lock_pointer for locking the pointer to its
position, and confine_pointer for locking the pointer to a region.
The lock_pointer and confine_pointer requests create the objects
@@ -75,7 +75,7 @@
<enum name="lifetime">
<description summary="constraint lifetime">
These values represent different lifetime semantics. They are passed
- as argument to the factory requests to specify how the constraint
+ as arguments to the factory requests to specify how the constraint
lifetimes should be managed.
</description>
<entry name="oneshot" value="1">
@@ -233,9 +233,9 @@
</description>
<arg name="surface_x" type="fixed"
- summary="x coordinate in surface-relative coordinates"/>
+ summary="surface-local x coordinate"/>
<arg name="surface_y" type="fixed"
- summary="y coordinate in surface-relative coordinates"/>
+ summary="surface-local y coordinate"/>
</request>
<request name="set_region">
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.3/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml
new/wayland-protocols-1.4/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml
---
old/wayland-protocols-1.3/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml
2015-11-17 04:46:57.000000000 +0100
+++
new/wayland-protocols-1.4/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml
2016-05-23 05:32:30.000000000 +0200
@@ -1,4 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?>
<protocol name="pointer_gestures_unstable_v1">
+
<interface name="zwp_pointer_gestures_v1" version="1">
<description summary="touchpad gestures">
A global interface to provide semantic touchpad gestures for a given
@@ -87,7 +89,7 @@
<event name="end">
<description summary="multi-finger swipe end">
This event is sent when a multi-finger swipe gesture ceases to
- be valid. This may happen when one or more finger is lifted or
+ be valid. This may happen when one or more fingers are lifted or
the gesture is cancelled.
When a gesture is cancelled, the client should undo state changes
@@ -106,7 +108,7 @@
gesture detected on an indirect input device such as a touchpad.
The gesture is usually initiated by multiple fingers moving towards
each other or away from each other, or by two or more fingers rotating
- around a logical center of gravity. The precise conditions of when
+ around a logical center of gravity. The precise conditions of when
such a gesture is detected are implementation-dependent.
A gesture consists of three stages: begin, update (optional) and end.
@@ -159,7 +161,7 @@
<event name="end">
<description summary="multi-finger pinch end">
This event is sent when a multi-finger pinch gesture ceases to
- be valid. This may happen when one or more finger is lifted or
+ be valid. This may happen when one or more fingers are lifted or
the gesture is cancelled.
When a gesture is cancelled, the client should undo state changes
@@ -171,4 +173,5 @@
<arg name="cancelled" type="int" summary="1 if the gesture was
cancelled, 0 otherwise"/>
</event>
</interface>
+
</protocol>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.3/unstable/relative-pointer/relative-pointer-unstable-v1.xml
new/wayland-protocols-1.4/unstable/relative-pointer/relative-pointer-unstable-v1.xml
---
old/wayland-protocols-1.3/unstable/relative-pointer/relative-pointer-unstable-v1.xml
2016-03-05 05:05:13.000000000 +0100
+++
new/wayland-protocols-1.4/unstable/relative-pointer/relative-pointer-unstable-v1.xml
2016-05-23 05:32:30.000000000 +0200
@@ -25,7 +25,7 @@
DEALINGS IN THE SOFTWARE.
</copyright>
- <description summary="Protocol for relative pointer motion events">
+ <description summary="protocol for relative pointer motion events">
This protocol specifies a set of interfaces used for making clients able to
receive relative pointer events not obstructed by barriers (such as the
monitor edge or other pointer barriers).
@@ -42,9 +42,9 @@
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. Backward
+ together with the corresponding interface version bump. Backward
incompatible changes are done by bumping the version number in the protocol
- and interface names and resetting the interface version. Once the protocol
+ and interface names and resetting the interface version. Once the protocol
is to be declared stable, the 'z' prefix and the version number in the
protocol and interface names are removed and the interface version number
is
reset.
@@ -111,7 +111,7 @@
Relative motions are not coupled to wl_pointer.motion events, and can be
sent in combination with such events, but also independently. There may
- also be scenarious where wl_pointer.motion is sent, but there is no
+ also be scenarios where wl_pointer.motion is sent, but there is no
relative motion. The order of an absolute and relative motion event
originating from the same physical motion is not guaranteed.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/wayland-protocols-1.3/unstable/tablet/tablet-unstable-v1.xml
new/wayland-protocols-1.4/unstable/tablet/tablet-unstable-v1.xml
--- old/wayland-protocols-1.3/unstable/tablet/tablet-unstable-v1.xml
2016-03-09 08:48:42.000000000 +0100
+++ new/wayland-protocols-1.4/unstable/tablet/tablet-unstable-v1.xml
2016-05-23 05:32:30.000000000 +0200
@@ -1,5 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="tablet_unstable_v1">
+
<copyright>
Copyright 2014 © Stephen "Lyude" Chandler Paul
Copyright 2015-2016 © Red Hat, Inc.
@@ -25,6 +26,7 @@
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
</copyright>
+
<description summary="Wayland protocol for graphics tablets">
This description provides a high-level overview of the interplay between
the interfaces defined this protocol. For details, see the protocol
@@ -35,7 +37,7 @@
binds to the tablet manager object which is just a proxy object. From
that, the client requests wp_tablet_manager.get_tablet_seat(wl_seat)
and that returns the actual interface that has all the tablets. With
- this indirection, we can avoid merging wp_tablet into the actual wayland
+ this indirection, we can avoid merging wp_tablet into the actual Wayland
protocol, a long-term benefit.
The wp_tablet_seat sends a "tablet added" event for each tablet
@@ -112,6 +114,7 @@
version number in the protocol and interface names are removed and the
interface version number is reset.
</description>
+
<interface name="zwp_tablet_manager_v1" version="1">
<description summary="controller object for graphic tablet devices">
An object that provides access to the graphics tablets available on this
@@ -207,7 +210,7 @@
The parameters hotspot_x and hotspot_y define the position of the
pointer surface relative to the pointer location. Its top-left corner
is always at (x, y) - (hotspot_x, hotspot_y), where (x, y) are the
- coordinates of the pointer location, in surface local coordinates.
+ coordinates of the pointer location, in surface-local coordinates.
On surface.attach requests to the pointer surface, hotspot_x and
hotspot_y are decremented by the x and y parameters passed to the
@@ -226,14 +229,14 @@
assigned by this request is the same as assigned by
wl_pointer.set_cursor meaning the same surface can be
used both as a wl_pointer cursor and a wp_tablet cursor. If the
- surface already has another role, it raises a protocol error
+ surface already has another role, it raises a protocol error.
The surface may be used on multiple tablets and across multiple
seats.
</description>
<arg name="serial" type="uint" summary="serial of the enter event"/>
<arg name="surface" type="object" interface="wl_surface"
allow-null="true"/>
- <arg name="hotspot_x" type="int" summary="x coordinate in
surface-relative coordinates"/>
- <arg name="hotspot_y" type="int" summary="y coordinate in
surface-relative coordinates"/>
+ <arg name="hotspot_x" type="int" summary="surface-local x coordinate"/>
+ <arg name="hotspot_y" type="int" summary="surface-local y coordinate"/>
</request>
<request name="destroy" type="destructor">
@@ -353,7 +356,7 @@
<event name="removed">
<description summary="tool removed">
This event is sent when the tool is removed from the system and will
- send no further events. Should the physical tool comes back into
+ send no further events. Should the physical tool come back into
proximity later, a new wp_tablet_tool object will be created.
It is compositor-dependent when a tool is removed. A compositor may
@@ -446,8 +449,8 @@
<description summary="motion event">
Sent whenever a tablet tool moves.
</description>
- <arg name="x" type="fixed" summary="surface-relative x coordinate"/>
- <arg name="y" type="fixed" summary="surface-relative y coordinate"/>
+ <arg name="x" type="fixed" summary="surface-local x coordinate"/>
+ <arg name="y" type="fixed" summary="surface-local y coordinate"/>
</event>
<event name="pressure">
@@ -455,7 +458,7 @@
Sent whenever the pressure axis on a tool changes. The value of this
event is normalized to a value between 0 and 65535.
- Note that pressure may be nonzero even when a tool not in logical
+ Note that pressure may be nonzero even when a tool is not in logical
contact. See the down and up events for more details.
</description>
<arg name="pressure" type="uint" summary="The current pressure value"/>
@@ -524,7 +527,7 @@
<enum name="button_state">
<description summary="physical button state">
- Describes the physical state of a button which provoked the button event
+ Describes the physical state of a button that produced the button event.
</description>
<entry name="released" value="0" summary="button is not pressed"/>
<entry name="pressed" value="1" summary="button is pressed"/>
@@ -548,7 +551,7 @@
<event name="frame">
<description summary="frame event">
Marks the end of a series of axis and/or button updates from the
- tablet. The wayland protocol requires axis updates to be sent
+ tablet. The Wayland protocol requires axis updates to be sent
sequentially, however all events within a frame should be considered
one hardware event.
</description>
@@ -601,9 +604,9 @@
this wp_tablet. This information may be used to gather additional
information about the device, e.g. through libwacom.
- A device may have more than one device path, if so, multiple
+ A device may have more than one device path. If so, multiple
wp_tablet.path events are sent. A device may be emulated and not
- have a device path, in that case this event will not be sent.
+ have a device path, and in that case this event will not be sent.
The format of the path is unspecified, it may be a device node, a
sysfs path, or some other identifier. It is up to the client to
@@ -634,4 +637,5 @@
</description>
</event>
</interface>
+
</protocol>
