mirror/RetroArch
1
0
Fork 0
mirror of https://github.com/libretro/RetroArch synced 2025-03-20 10:20:51 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #8250 from orbea/protocols

Browse Source 
qb: Allow falling back to a bundled wayland-protocols when not found.
This commit is contained in:
Twinaphex 2019-02-11 00:48:37 +01:00 committed by GitHub
commit 17f90a3624
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
12 changed files with 2651 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
deps/wayland-protocols/COPYING vendored Normal file
View File

@ -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

141
deps/wayland-protocols/README vendored Normal file
View File

@ -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.

5
deps/wayland-protocols/stable/xdg-shell/README vendored Normal file
View File

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

1144
deps/wayland-protocols/stable/xdg-shell/xdg-shell.xml vendored Normal file
View File

File diff suppressed because it is too large Load Diff

4
deps/wayland-protocols/unstable/idle-inhibit/README vendored Normal file
View File

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

83
deps/wayland-protocols/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml vendored Normal file
View File

@ -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>

4
deps/wayland-protocols/unstable/xdg-decoration/README vendored Normal file
View File

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

156
deps/wayland-protocols/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml vendored Normal file
View File

@ -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>

4
deps/wayland-protocols/unstable/xdg-shell/README vendored Normal file
View File

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

1044
deps/wayland-protocols/unstable/xdg-shell/xdg-shell-unstable-v6.xml vendored Normal file
View File

File diff suppressed because it is too large Load Diff

41
gfx/common/wayland/generate_wayland_protos.sh
View File

@ -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
[ -d "$protos" ] || continue
WAYLAND_PROTOS="$protos"
break
done
if [ "$PROTOS" != 'no' ]; then
for protos in "$SHARE_DIR" /usr/local/share/wayland-protocols /usr/share/wayland-protocols; do
[ -d "$protos" ] || continue
WAYLAND_PROTOS="$protos"
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" $CODEGEN "$WAYLAND_PROTOS/unstable/xdg-shell/xdg-shell-unstable-v6.xml" ./xdg-shell-unstable-v6.c
"$WAYSCAN" client-header "$WAYLAND_PROTOS/$XDG_SHELL_UNSTABLE" ./xdg-shell-unstable-v6.h
"$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" $CODEGEN "$WAYLAND_PROTOS/stable/xdg-shell/xdg-shell.xml" ./xdg-shell.c
"$WAYSCAN" client-header "$WAYLAND_PROTOS/$XDG_SHELL" ./xdg-shell.h
"$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" $CODEGEN "$WAYLAND_PROTOS/unstable/idle-inhibit/idle-inhibit-unstable-v1.xml" ./idle-inhibit-unstable-v1.c
"$WAYSCAN" client-header "$WAYLAND_PROTOS/$IDLE_INHIBIT_UNSTABLE" ./idle-inhibit-unstable-v1.h
"$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" $CODEGEN "$WAYLAND_PROTOS/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml" ./xdg-decoration-unstable-v1.c
"$WAYSCAN" client-header "$WAYLAND_PROTOS/$XDG_DECORATION_UNSTABLE" ./xdg-decoration-unstable-v1.h
"$WAYSCAN" $CODEGEN "$WAYLAND_PROTOS/$XDG_DECORATION_UNSTABLE" ./xdg-decoration-unstable-v1.c

10
qb/config.libs.sh
View File

@ -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 ] &&
[ "$HAVE_WAYLAND_SCANNER" = yes ] &&
if [ "$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" ||
die 1 'Error: Failed generating wayland protocols.'
./gfx/common/wayland/generate_wayland_protos.sh \
-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'