From e2891a9c6f422c66a9b3f3af246bab0c154d75a3 Mon Sep 17 00:00:00 2001 From: ReenigneArcher <42013603+ReenigneArcher@users.noreply.github.com> Date: Mon, 9 Oct 2023 21:56:53 -0400 Subject: [PATCH] build(deps): use submodules for wayland protocols --- .gitmodules | 8 + cmake/compile_definitions/linux.cmake | 4 +- cmake/macros/linux.cmake | 10 +- third-party/wayland-protocols | 1 + .../wlr-export-dmabuf-unstable-v1.xml | 203 ---------------- .../xdg-output-unstable-v1.xml | 220 ------------------ third-party/wlr-protocols | 1 + 7 files changed, 17 insertions(+), 430 deletions(-) create mode 160000 third-party/wayland-protocols delete mode 100644 third-party/wayland-protocols/wlr-export-dmabuf-unstable-v1.xml delete mode 100644 third-party/wayland-protocols/xdg-output-unstable-v1.xml create mode 160000 third-party/wlr-protocols 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