Merge pull request #8250 from orbea/protocols

qb: Allow falling back to a bundled wayland-protocols when not found.

deps/wayland-protocols/COPYING

@@ -0,0 +1,33 @@
+Copyright © 2008-2013 Kristian Høgsberg
+Copyright © 2010-2013 Intel Corporation
+Copyright © 2013      Rafael Antognolli
+Copyright © 2013      Jasper St. Pierre
+Copyright © 2014      Jonas Ådahl
+Copyright © 2014      Jason Ekstrand
+Copyright © 2014-2015 Collabora, Ltd.
+Copyright © 2015      Red Hat Inc.
+
+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.
+
+---
+
+The above is the version of the MIT "Expat" License used by X.org:
+
+    http://cgit.freedesktop.org/xorg/xserver/tree/COPYING

deps/wayland-protocols/README

@@ -0,0 +1,141 @@
+Wayland protocols
+-----------------
+
+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.
+
+A protocol in wayland-protocols consists of a directory containing a set
+of XML files containing the protocol specification, and a README file
+containing detailed state and a list of maintainers.
+
+Protocol directory tree structure
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Protocols may be 'stable', 'unstable' or 'deprecated', and the interface
+and protocol names as well as place in the directory tree will reflect
+this.
+
+A stable protocol is a protocol which has been declared stable by
+the maintainers. Changes to such protocols will always be backward
+compatible.
+
+An unstable protocol is a protocol currently under development and this
+will be reflected in the protocol and interface names. See <<Unstable
+naming convention>>.
+
+A deprecated protocol is a protocol that has either been replaced by some
+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 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
+deprecated protocols are placed in the +deprecated/+ directory.
+
+Protocol development procedure
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+To propose a new protocol, create a patch adding the relevant files and
+Makefile.am entry to the wayland-protocols git repository with the
+explanation and motivation in the commit message. Then send the patch to
+the wayland-devel@lists.freedesktop.org mailing list using
+'git send-email' with the subject prefix 'RFC wayland-protocols' or
+'PATCH wayland-protocols' depending on what state the protocol is in.
+
+To propose changes to existing protocols, create a patch with the
+changes and send it to the list mentioned above while also CC:ing the
+maintainers mentioned in the README file. Use the same rule for adding a
+subject prefix as above and method for sending the patch.
+
+If the changes are backward incompatible changes to an unstable protocol,
+see <<Unstable protocol changes>>.
+
+Interface naming convention
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+All protocols should avoid using generic namespaces or no namespaces in
+the protocol interface names in order to minimize risk that the generated
+C API collides with other C API. Interface names that may collide with
+interface names from other protocols should also be avoided.
+
+For generic protocols not limited to certain configurations (such as
+specific desktop environment or operating system) the +wp_+ prefix
+should be used on all interfaces in the protocol.
+
+For operating system specific protocols, the interfaces should be
+prefixed with both +wp_+ and the operating system, for example
++wp_linux_+, or +wp_freebsd_+, etc.
+
+Unstable naming convention
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+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 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
+XML, and interface names in the protocol.
+
+Minor versions are the version attributes of the interfaces in the XML.
+There may be more than one minor version per protocol, if there are more
+than one global.
+
+The XML file and protocol name also has the word 'unstable' in them, and
+all of the interfaces in the protocol are prefixed with +z+ and
+suffixed with the major version number.
+
+For example, an unstable protocol called foo-bar with major version 2
+containing the two interfaces wp_foo and wp_bar both minor version 1 will
+be placed in the directory +unstable/foo-bar/+ consisting of one file
+called +README+ and one called +foo-bar-unstable-v2.xml+. The XML file
+will consist of two interfaces called +zwp_foo_v2+ and +zwp_bar_v2+ with
+the +version+ attribute set to +1+.
+
+Unstable protocol changes
+~~~~~~~~~~~~~~~~~~~~~~~~~
+During the development of a new protocol it is possible that backward
+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 for how to
+do so is the following:
+
+  . Make a copy of the XML file with the major version increased by +1+.
+  . Increase the major version number in the protocol XML by +1+.
+  . Increase the major version number in all of the interfaces in the
+    XML by +1+.
+  . Reset the minor version number (interface version attribute) of all
+    the interfaces to +1+.
+
+Backward compatible changes within a major unstable version can be done
+in the regular way as done in core Wayland or in stable protocols.
+
+Declaring a protocol stable
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Once it is decided that a protocol should be declared stable, meaning no
+more backward incompatible changes will ever be allowed, one last
+breakage is needed.
+
+The procedure of doing this is the following:
+
+  . Create a new directory in the +stable/+ toplevel directory with the
+    same name as the protocol directory in the +unstable/+ directory.
+  . Copy the final version of the XML that is the version that was
+    decided to be declared stable into the new directory. The target name
+    should be the same name as the protocol directory but with the +.xml+
+    suffix.
+  . Rename the name of the protocol in the XML by removing the
+    'unstable' part and the major version number.
+  . Remove the +z+ prefix and the major version number suffix from all
+    of the interfaces in the protocol.
+  . Reset all of the interface version attributes to +1+.
+  . Update the +README+ file in the unstable directory and create a new
+    +README+ file in the new directory.
+
+Releases
+~~~~~~~~
+Each release of wayland-protocols finalizes the version of the protocols
+to their state they had at that time.

deps/wayland-protocols/stable/xdg-shell/README

@@ -0,0 +1,5 @@
+xdg shell protocol
+
+Maintainers:
+Jonas Ådahl <jadahl@gmail.com>
+Mike Blumenkrantz <zmike@osg.samsung.com>

deps/wayland-protocols/unstable/idle-inhibit/README

@@ -0,0 +1,4 @@
+Screensaver inhibition protocol
+
+Maintainers:
+Bryce Harrington <bryce@osg.samsung.com>

deps/wayland-protocols/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml

@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="idle_inhibit_unstable_v1">
+
+  <copyright>
+    Copyright © 2015 Samsung Electronics Co., 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="zwp_idle_inhibit_manager_v1" version="1">
+    <description summary="control behavior when display idles">
+      This interface permits inhibiting the idle behavior such as screen
+      blanking, locking, and screensaving.  The client binds the idle manager
+      globally, then creates idle-inhibitor objects for each surface.
+
+      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 incompatible changes are done by bumping the version number in
+      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.
+    </description>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroy the idle inhibitor object">
+	Destroy the inhibit manager.
+      </description>
+    </request>
+
+    <request name="create_inhibitor">
+      <description summary="create a new inhibitor object">
+	Create a new inhibitor object associated with the given surface.
+      </description>
+      <arg name="id" type="new_id" interface="zwp_idle_inhibitor_v1"/>
+      <arg name="surface" type="object" interface="wl_surface"
+	   summary="the surface that inhibits the idle behavior"/>
+    </request>
+
+  </interface>
+
+  <interface name="zwp_idle_inhibitor_v1" version="1">
+    <description summary="context object for inhibiting idle behavior">
+      An idle inhibitor prevents the output that the associated surface is
+      visible on from being set to a state where it is not visually usable due
+      to lack of user interaction (e.g. blanked, dimmed, locked, set to power
+      save, etc.)  Any screensaver processes are also blocked from displaying.
+
+      If the surface is destroyed, unmapped, becomes occluded, loses
+      visibility, or otherwise becomes not visually relevant for the user, the
+      idle inhibitor will not be honored by the compositor; if the surface
+      subsequently regains visibility the inhibitor takes effect once again.
+      Likewise, the inhibitor isn't honored if the system was already idled at
+      the time the inhibitor was established, although if the system later
+      de-idles and re-idles the inhibitor will take effect.
+    </description>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroy the idle inhibitor object">
+	Remove the inhibitor effect from the associated wl_surface.
+      </description>
+    </request>
+
+  </interface>
+</protocol>

deps/wayland-protocols/unstable/xdg-decoration/README

@@ -0,0 +1,4 @@
+xdg_decoration protocol
+
+Maintainers:
+Simon Ser <contact@emersion.fr>

deps/wayland-protocols/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml

@@ -0,0 +1,156 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xdg_decoration_unstable_v1">
+  <copyright>
+    Copyright © 2018 Simon Ser
+
+    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="zxdg_decoration_manager_v1" version="1">
+    <description summary="window decoration manager">
+      This interface allows a compositor to announce support for server-side
+      decorations.
+
+      A window decoration is a set of window controls as deemed appropriate by
+      the party managing them, such as user interface components used to move,
+      resize and change a window's state.
+
+      A client can use this protocol to request being decorated by a supporting
+      compositor.
+
+      If compositor and client do not negotiate the use of a server-side
+      decoration using this protocol, clients continue to self-decorate as they
+      see fit.
+
+      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 incompatible changes are done by bumping the version number in
+      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.
+    </description>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroy the decoration manager object">
+        Destroy the decoration manager. This doesn't destroy objects created
+        with the manager.
+      </description>
+    </request>
+
+    <request name="get_toplevel_decoration">
+      <description summary="create a new toplevel decoration object">
+        Create a new decoration object associated with the given toplevel.
+
+        Creating an xdg_toplevel_decoration from an xdg_toplevel which has a
+        buffer attached or committed is a client error, and any attempts by a
+        client to attach or manipulate a buffer prior to the first
+        xdg_toplevel_decoration.configure event must also be treated as
+        errors.
+      </description>
+      <arg name="id" type="new_id" interface="zxdg_toplevel_decoration_v1"/>
+      <arg name="toplevel" type="object" interface="xdg_toplevel"/>
+    </request>
+  </interface>
+
+  <interface name="zxdg_toplevel_decoration_v1" version="1">
+    <description summary="decoration object for a toplevel surface">
+      The decoration object allows the compositor to toggle server-side window
+      decorations for a toplevel surface. The client can request to switch to
+      another mode.
+
+      The xdg_toplevel_decoration object must be destroyed before its
+      xdg_toplevel.
+    </description>
+
+    <enum name="error">
+      <entry name="unconfigured_buffer" value="0"
+        summary="xdg_toplevel has a buffer attached before configure"/>
+      <entry name="already_constructed" value="1"
+        summary="xdg_toplevel already has a decoration object"/>
+      <entry name="orphaned" value="2"
+        summary="xdg_toplevel destroyed before the decoration object"/>
+    </enum>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroy the decoration object">
+        Switch back to a mode without any server-side decorations at the next
+        commit.
+      </description>
+    </request>
+
+    <enum name="mode">
+      <description summary="window decoration modes">
+        These values describe window decoration modes.
+      </description>
+      <entry name="client_side" value="1"
+        summary="no server-side window decoration"/>
+      <entry name="server_side" value="2"
+        summary="server-side window decoration"/>
+    </enum>
+
+    <request name="set_mode">
+      <description summary="set the decoration mode">
+        Set the toplevel surface decoration mode. This informs the compositor
+        that the client prefers the provided decoration mode.
+
+        After requesting a decoration mode, the compositor will respond by
+        emitting a xdg_surface.configure event. The client should then update
+        its content, drawing it without decorations if the received mode is
+        server-side decorations. The client must also acknowledge the configure
+        when committing the new content (see xdg_surface.ack_configure).
+
+        The compositor can decide not to use the client's mode and enforce a
+        different mode instead.
+
+        Clients whose decoration mode depend on the xdg_toplevel state may send
+        a set_mode request in response to a xdg_surface.configure event and wait
+        for the next xdg_surface.configure event to prevent unwanted state.
+        Such clients are responsible for preventing configure loops and must
+        make sure not to send multiple successive set_mode requests with the
+        same decoration mode.
+      </description>
+      <arg name="mode" type="uint" enum="mode" summary="the decoration mode"/>
+    </request>
+
+    <request name="unset_mode">
+      <description summary="unset the decoration mode">
+        Unset the toplevel surface decoration mode. This informs the compositor
+        that the client doesn't prefer a particular decoration mode.
+
+        This request has the same semantics as set_mode.
+      </description>
+    </request>
+
+    <event name="configure">
+      <description summary="suggest a surface change">
+        The configure event asks the client to change its decoration mode. The
+        configured state should not be applied immediately. Clients must send an
+        ack_configure in response to this event. See xdg_surface.configure and
+        xdg_surface.ack_configure for details.
+
+        A configure event can be sent at any time. The specified mode must be
+        obeyed by the client.
+      </description>
+      <arg name="mode" type="uint" enum="mode" summary="the decoration mode"/>
+    </event>
+  </interface>
+</protocol>

deps/wayland-protocols/unstable/xdg-shell/README

@@ -0,0 +1,4 @@
+xdg shell protocol
+
+Maintainers:
+Jasper St. Pierre <jstpierre@mecheye.net>

gfx/common/wayland/generate_wayland_protos.sh

@@ -6,6 +6,7 @@ cd -- "$(cd -- "${0%/*}/" && pwd -P)"
 
 . ../../../qb/qb.init.sh
 
+PROTOS=''
 SCANNER_VERSION=''
 SHARE_DIR=''
 
@@ -14,6 +15,7 @@ usage="generate_wayland_protos.sh - Generates wayland protocols.
   Usage: generate_wayland_protos.sh [OPTIONS]
     -c, --codegen version   Sets the wayland scanner compatibility version.
     -h, --help              Shows this message.
+    -p, --protos yes|no     Set to 'no' to use the bundled wayland-protocols.
     -s, --share path        Sets the path of the wayland protocols directory."
 
 while [ $# -gt 0 ]; do
@@ -23,6 +25,7 @@ while [ $# -gt 0 ]; do
       -- ) break ;;
       -c|--codegen ) SCANNER_VERSION="$1"; shift ;;
       -h|--help ) die 0 "$usage" ;;
+      -p|--protos ) PROTOS="$1"; shift ;;
       -s|--share ) SHARE_DIR="$1/wayland-protocols"; shift ;;
       * ) die 1 "Unrecognized option '$option', use -h for help." ;;
    esac
@@ -34,13 +37,18 @@ WAYSCAN="$(exists wayland-scanner || :)"
 
 WAYLAND_PROTOS=''
 
-for protos in "$SHARE_DIR" /usr/local/share/wayland-protocols /usr/share/wayland-protocols; do
+if [ "$PROTOS" != 'no' ]; then
-   [ -d "$protos" ] || continue
+   for protos in "$SHARE_DIR" /usr/local/share/wayland-protocols /usr/share/wayland-protocols; do
-   WAYLAND_PROTOS="$protos"
+      [ -d "$protos" ] || continue
-   break
+      WAYLAND_PROTOS="$protos"
-done
+      break
+   done
+fi
 
-[ "${WAYLAND_PROTOS}" ] || die 1 'Error: No wayland-protocols directory found.'
+if [ -z "${WAYLAND_PROTOS}" ]; then
+   WAYLAND_PROTOS='../../../deps/wayland-protocols'
+   die : 'Notice: Using the bundled wayland-protocols.'
+fi
 
 if [ "$SCANNER_VERSION" = '1.12' ]; then
    CODEGEN=code
@@ -48,18 +56,23 @@ else
    CODEGEN=private-code
 fi
 
+XDG_SHELL_UNSTABLE='unstable/xdg-shell/xdg-shell-unstable-v6.xml'
+XDG_SHELL='stable/xdg-shell/xdg-shell.xml'
+XDG_DECORATION_UNSTABLE='unstable/xdg-decoration/xdg-decoration-unstable-v1.xml'
+IDLE_INHIBIT_UNSTABLE='unstable/idle-inhibit/idle-inhibit-unstable-v1.xml'
+
 #Generate xdg-shell_v6 header and .c files
-"$WAYSCAN" client-header "$WAYLAND_PROTOS/unstable/xdg-shell/xdg-shell-unstable-v6.xml" ./xdg-shell-unstable-v6.h
+"$WAYSCAN" client-header "$WAYLAND_PROTOS/$XDG_SHELL_UNSTABLE" ./xdg-shell-unstable-v6.h
-"$WAYSCAN" $CODEGEN "$WAYLAND_PROTOS/unstable/xdg-shell/xdg-shell-unstable-v6.xml" ./xdg-shell-unstable-v6.c
+"$WAYSCAN" $CODEGEN "$WAYLAND_PROTOS/$XDG_SHELL_UNSTABLE" ./xdg-shell-unstable-v6.c
 
 #Generate xdg-shell header and .c files
-"$WAYSCAN" client-header "$WAYLAND_PROTOS/stable/xdg-shell/xdg-shell.xml" ./xdg-shell.h
+"$WAYSCAN" client-header "$WAYLAND_PROTOS/$XDG_SHELL" ./xdg-shell.h
-"$WAYSCAN" $CODEGEN "$WAYLAND_PROTOS/stable/xdg-shell/xdg-shell.xml" ./xdg-shell.c
+"$WAYSCAN" $CODEGEN "$WAYLAND_PROTOS/$XDG_SHELL" ./xdg-shell.c
 
 #Generate idle-inhibit header and .c files
-"$WAYSCAN" client-header "$WAYLAND_PROTOS/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml" ./idle-inhibit-unstable-v1.h
+"$WAYSCAN" client-header "$WAYLAND_PROTOS/$IDLE_INHIBIT_UNSTABLE" ./idle-inhibit-unstable-v1.h
-"$WAYSCAN" $CODEGEN "$WAYLAND_PROTOS/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml" ./idle-inhibit-unstable-v1.c
+"$WAYSCAN" $CODEGEN "$WAYLAND_PROTOS/$IDLE_INHIBIT_UNSTABLE" ./idle-inhibit-unstable-v1.c
 
 #Generate xdg-decoration header and .c files
-"$WAYSCAN" client-header "$WAYLAND_PROTOS/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml" ./xdg-decoration-unstable-v1.h
+"$WAYSCAN" client-header "$WAYLAND_PROTOS/$XDG_DECORATION_UNSTABLE" ./xdg-decoration-unstable-v1.h
-"$WAYSCAN" $CODEGEN "$WAYLAND_PROTOS/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml" ./xdg-decoration-unstable-v1.c
+"$WAYSCAN" $CODEGEN "$WAYLAND_PROTOS/$XDG_DECORATION_UNSTABLE" ./xdg-decoration-unstable-v1.c

qb/config.libs.sh

@@ -435,12 +435,14 @@ check_pkgconf DBUS dbus-1
 check_val '' XEXT -lXext '' xext '' '' false
 check_val '' XF86VM -lXxf86vm '' xxf86vm '' '' false
 
-if [ "$HAVE_WAYLAND_PROTOS" = yes ] &&
+if [ "$HAVE_WAYLAND_SCANNER" = yes ] &&
-   [ "$HAVE_WAYLAND_SCANNER" = yes ] &&
    [ "$HAVE_WAYLAND_CURSOR" = yes ] &&
    [ "$HAVE_WAYLAND" = yes ]; then
-    ./gfx/common/wayland/generate_wayland_protos.sh -c "$WAYLAND_SCANNER_VERSION" -s "$SHARE_DIR" ||
+      ./gfx/common/wayland/generate_wayland_protos.sh \
-       die 1 'Error: Failed generating wayland protocols.'
+         -c "$WAYLAND_SCANNER_VERSION" \
+         -p "$HAVE_WAYLAND_PROTOS" \
+         -s "$SHARE_DIR" ||
+         die 1 'Error: Failed generating wayland protocols.'
 else
     die : 'Notice: wayland libraries not found, disabling wayland support.'
     HAVE_WAYLAND='no'