diff --git a/.gitmodules b/.gitmodules
index 615b2175e67..92820c24c47 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -58,3 +58,11 @@
path = third-party/ffmpeg-linux-powerpc64le
url = https://github.com/LizardByte/build-deps
branch = ffmpeg-linux-powerpc64le
+[submodule "third-party/wayland-protocols"]
+ path = third-party/wayland-protocols
+ url = https://gitlab.freedesktop.org/wayland/wayland-protocols
+ branch = main
+[submodule "third-party/wlr-protocols"]
+ path = third-party/wlr-protocols
+ url = https://gitlab.freedesktop.org/wlroots/wlr-protocols
+ branch = master
diff --git a/cmake/compile_definitions/linux.cmake b/cmake/compile_definitions/linux.cmake
index 97bd7eb5d00..f28152ee9bb 100644
--- a/cmake/compile_definitions/linux.cmake
+++ b/cmake/compile_definitions/linux.cmake
@@ -127,8 +127,8 @@ endif()
if(WAYLAND_FOUND)
add_compile_definitions(SUNSHINE_BUILD_WAYLAND)
- GEN_WAYLAND(xdg-output-unstable-v1)
- GEN_WAYLAND(wlr-export-dmabuf-unstable-v1)
+ GEN_WAYLAND("wayland-protocols" "unstable/xdg-output" xdg-output-unstable-v1)
+ GEN_WAYLAND("wlr-protocols" "unstable" wlr-export-dmabuf-unstable-v1)
include_directories(
SYSTEM
diff --git a/cmake/macros/linux.cmake b/cmake/macros/linux.cmake
index fea94fe870a..d84d0452568 100644
--- a/cmake/macros/linux.cmake
+++ b/cmake/macros/linux.cmake
@@ -1,21 +1,21 @@
# linux specific macros
# GEN_WAYLAND: args = `filename`
-macro(GEN_WAYLAND filename)
+macro(GEN_WAYLAND wayland_directory subdirectory filename)
file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/generated-src)
message("wayland-scanner private-code \
-${CMAKE_SOURCE_DIR}/third-party/wayland-protocols/${filename}.xml \
+${CMAKE_SOURCE_DIR}/third-party/${wayland_directory}/${subdirectory}/${filename}.xml \
${CMAKE_BINARY_DIR}/generated-src/${filename}.c")
message("wayland-scanner client-header \
-${CMAKE_SOURCE_DIR}/third-party/wayland-protocols/${filename}.xml \
+${CMAKE_SOURCE_DIR}/third-party/${wayland_directory}/${subdirectory}/${filename}.xml \
${CMAKE_BINARY_DIR}/generated-src/${filename}.h")
execute_process(
COMMAND wayland-scanner private-code
- ${CMAKE_SOURCE_DIR}/third-party/wayland-protocols/${filename}.xml
+ ${CMAKE_SOURCE_DIR}/third-party/${wayland_directory}/${subdirectory}/${filename}.xml
${CMAKE_BINARY_DIR}/generated-src/${filename}.c
COMMAND wayland-scanner client-header
- ${CMAKE_SOURCE_DIR}/third-party/wayland-protocols/${filename}.xml
+ ${CMAKE_SOURCE_DIR}/third-party/${wayland_directory}/${subdirectory}/${filename}.xml
${CMAKE_BINARY_DIR}/generated-src/${filename}.h
RESULT_VARIABLE EXIT_INT
diff --git a/third-party/wayland-protocols b/third-party/wayland-protocols
new file mode 160000
index 00000000000..681c33c8547
--- /dev/null
+++ b/third-party/wayland-protocols
@@ -0,0 +1 @@
+Subproject commit 681c33c8547d6aefe24455ba2bffe1c5ae11fee5
diff --git a/third-party/wayland-protocols/wlr-export-dmabuf-unstable-v1.xml b/third-party/wayland-protocols/wlr-export-dmabuf-unstable-v1.xml
deleted file mode 100644
index 751f7efbf39..00000000000
--- a/third-party/wayland-protocols/wlr-export-dmabuf-unstable-v1.xml
+++ /dev/null
@@ -1,203 +0,0 @@
-
-
-
- Copyright © 2018 Rostislav Pehlivanov
-
- 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.
-
-
-
- An interface to capture surfaces in an efficient way by exporting DMA-BUFs.
-
- 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.
-
-
-
-
- This object is a manager with which to start capturing from sources.
-
-
-
-
- Capture the next frame of a an entire output.
-
-
-
-
-
-
-
-
- All objects created by the manager will still remain valid, until their
- appropriate destroy request has been called.
-
-
-
-
-
-
- This object represents a single DMA-BUF frame.
-
- If the capture is successful, the compositor will first send a "frame"
- event, followed by one or several "object". When the frame is available
- for readout, the "ready" event is sent.
-
- If the capture failed, the "cancel" event is sent. This can happen anytime
- before the "ready" event.
-
- Once either a "ready" or a "cancel" event is received, the client should
- destroy the frame. Once an "object" event is received, the client is
- responsible for closing the associated file descriptor.
-
- All frames are read-only and may not be written into or altered.
-
-
-
-
- Special flags that should be respected by the client.
-
-
-
-
-
-
- Main event supplying the client with information about the frame. If the
- capture didn't fail, this event is always emitted first before any other
- events.
-
- This event is followed by a number of "object" as specified by the
- "num_objects" argument.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Event which serves to supply the client with the file descriptors
- containing the data for each object.
-
- After receiving this event, the client must always close the file
- descriptor as soon as they're done with it and even if the frame fails.
-
-
-
-
-
-
-
-
-
-
-
- This event is sent as soon as the frame is presented, indicating it is
- available for reading. This event includes the time at which
- presentation happened at.
-
- The timestamp is expressed as tv_sec_hi, tv_sec_lo, tv_nsec triples,
- each component being an unsigned 32-bit value. Whole seconds are in
- tv_sec which is a 64-bit value combined from tv_sec_hi and tv_sec_lo,
- and the additional fractional part in tv_nsec as nanoseconds. Hence,
- for valid timestamps tv_nsec must be in [0, 999999999]. The seconds part
- may have an arbitrary offset at start.
-
- After receiving this event, the client should destroy this object.
-
-
-
-
-
-
-
-
- Indicates reason for cancelling the frame.
-
-
-
-
-
-
-
-
- If the capture failed or if the frame is no longer valid after the
- "frame" event has been emitted, this event will be used to inform the
- client to scrap the frame.
-
- If the failure is temporary, the client may capture again the same
- source. If the failure is permanent, any further attempts to capture the
- same source will fail again.
-
- After receiving this event, the client should destroy this object.
-
-
-
-
-
-
- Unreferences the frame. This request must be called as soon as its no
- longer used.
-
- It can be called at any time by the client. The client will still have
- to close any FDs it has been given.
-
-
-
-
diff --git a/third-party/wayland-protocols/xdg-output-unstable-v1.xml b/third-party/wayland-protocols/xdg-output-unstable-v1.xml
deleted file mode 100644
index 9a5b7900097..00000000000
--- a/third-party/wayland-protocols/xdg-output-unstable-v1.xml
+++ /dev/null
@@ -1,220 +0,0 @@
-
-
-
-
- Copyright © 2017 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.
-
-
-
- This protocol aims at describing outputs in a way which is more in line
- with the concept of an output on desktop oriented systems.
-
- Some information are more specific to the concept of an output for
- a desktop oriented system and may not make sense in other applications,
- such as IVI systems for example.
-
- Typically, the global compositor space on a desktop system is made of
- a contiguous or overlapping set of rectangular regions.
-
- Some of the information provided in this protocol might be identical
- to their counterparts already available from wl_output, in which case
- the information provided by this protocol should be preferred to their
- equivalent in wl_output. The goal is to move the desktop specific
- concepts (such as output location within the global compositor space,
- the connector name and types, etc.) out of the core wl_output protocol.
-
- 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.
-
-
-
-
- A global factory interface for xdg_output objects.
-
-
-
-
- Using this request a client can tell the server that it is not
- going to use the xdg_output_manager object anymore.
-
- Any objects already created through this instance are not affected.
-
-
-
-
-
- This creates a new xdg_output object for the given wl_output.
-
-
-
-
-
-
-
-
- An xdg_output describes part of the compositor geometry.
-
- This typically corresponds to a monitor that displays part of the
- compositor space.
-
- For objects version 3 onwards, after all xdg_output properties have been
- sent (when the object is created and when properties are updated), a
- wl_output.done event is sent. This allows changes to the output
- properties to be seen as atomic, even if they happen via multiple events.
-
-
-
-
- Using this request a client can tell the server that it is not
- going to use the xdg_output object anymore.
-
-
-
-
-
- The position event describes the location of the wl_output within
- the global compositor space.
-
- The logical_position event is sent after creating an xdg_output
- (see xdg_output_manager.get_xdg_output) and whenever the location
- of the output changes within the global compositor space.
-
-
-
-
-
-
-
- The logical_size event describes the size of the output in the
- global compositor space.
-
- For example, a surface without any buffer scale, transformation
- nor rotation set, with the size matching the logical_size will
- have the same size as the corresponding output when displayed.
-
- Most regular Wayland clients should not pay attention to the
- logical size and would rather rely on xdg_shell interfaces.
-
- Some clients such as Xwayland, however, need this to configure
- their surfaces in the global compositor space as the compositor
- may apply a different scale from what is advertised by the output
- scaling property (to achieve fractional scaling, for example).
-
- For example, for a wl_output mode 3840×2160 and a scale factor 2:
-
- - A compositor not scaling the surface buffers will advertise a
- logical size of 3840×2160,
-
- - A compositor automatically scaling the surface buffers will
- advertise a logical size of 1920×1080,
-
- - A compositor using a fractional scale of 1.5 will advertise a
- logical size of 2560×1440.
-
- For example, for a wl_output mode 1920×1080 and a 90 degree rotation,
- the compositor will advertise a logical size of 1080x1920.
-
- The logical_size event is sent after creating an xdg_output
- (see xdg_output_manager.get_xdg_output) and whenever the logical
- size of the output changes, either as a result of a change in the
- applied scale or because of a change in the corresponding output
- mode(see wl_output.mode) or transform (see wl_output.transform).
-
-
-
-
-
-
-
- This event is sent after all other properties of an xdg_output
- have been sent.
-
- This allows changes to the xdg_output properties to be seen as
- atomic, even if they happen via multiple events.
-
- For objects version 3 onwards, this event is deprecated. Compositors
- are not required to send it anymore and must send wl_output.done
- instead.
-
-
-
-
-
-
-
- Many compositors will assign names to their outputs, show them to the
- user, allow them to be configured by name, etc. The client may wish to
- know this name as well to offer the user similar behaviors.
-
- The naming convention is compositor defined, but limited to
- alphanumeric characters and dashes (-). Each name is unique among all
- wl_output globals, but if a wl_output global is destroyed the same name
- may be reused later. The names will also remain consistent across
- sessions with the same hardware and software configuration.
-
- Examples of names include 'HDMI-A-1', 'WL-1', 'X11-1', etc. However, do
- not assume that the name is a reflection of an underlying DRM
- connector, X11 connection, etc.
-
- The name event is sent after creating an xdg_output (see
- xdg_output_manager.get_xdg_output). This event is only sent once per
- xdg_output, and the name does not change over the lifetime of the
- wl_output global.
-
-
-
-
-
-
- Many compositors can produce human-readable descriptions of their
- outputs. The client may wish to know this description as well, to
- communicate the user for various purposes.
-
- The description is a UTF-8 string with no convention defined for its
- contents. Examples might include 'Foocorp 11" Display' or 'Virtual X11
- output via :1'.
-
- The description event is sent after creating an xdg_output (see
- xdg_output_manager.get_xdg_output) and whenever the description
- changes. The description is optional, and may not be sent at all.
-
- For objects of version 2 and lower, this event is only sent once per
- xdg_output, and the description does not change over the lifetime of
- the wl_output global.
-
-
-
-
-
-
diff --git a/third-party/wlr-protocols b/third-party/wlr-protocols
new file mode 160000
index 00000000000..4264185db3b
--- /dev/null
+++ b/third-party/wlr-protocols
@@ -0,0 +1 @@
+Subproject commit 4264185db3b7e961e7f157e1cc4fd0ab75137568