├── .gitignore ├── .gitlab-ci.yml ├── .kde-ci.yml ├── CMakeLists.txt ├── COPYING.LIB ├── LICENSES ├── BSD-3-Clause.txt ├── CC0-1.0.txt ├── LGPL-2.1-or-later.txt ├── MIT-CMU.txt └── MIT.txt ├── PlasmaWaylandProtocolsConfig.cmake.in ├── README.md ├── autotests ├── CMakeLists.txt ├── CMakeListst.txt └── build.c ├── cmake └── Modules │ └── FindWaylandProtocols.cmake ├── metainfo.yaml └── src ├── CMakeLists.txt └── protocols ├── TODOKF6.md ├── appmenu.xml ├── blur.xml ├── contrast.xml ├── dpms.xml ├── fake-input.xml ├── fullscreen-shell.xml ├── idle.xml ├── kde-external-brightness-v1.xml ├── kde-lockscreen-overlay-v1.xml ├── kde-output-device-v2.xml ├── kde-output-management-v2.xml ├── kde-output-order-v1.xml ├── kde-primary-output-v1.xml ├── kde-screen-edge-v1.xml ├── keystate.xml ├── org-kde-plasma-virtual-desktop.xml ├── output-management.xml ├── outputdevice.xml ├── plasma-shell.xml ├── plasma-window-management.xml ├── remote-access.xml ├── server-decoration-palette.xml ├── server-decoration.xml ├── shadow.xml ├── slide.xml ├── surface-extension.xml ├── text-input-unstable-v2.xml ├── text-input.xml ├── wayland-eglstream-controller.xml └── zkde-screencast-unstable-v1.xml /.gitignore: -------------------------------------------------------------------------------- 1 | # Ignore the following files 2 | .vscode 3 | *~ 4 | *.[oa] 5 | *.diff 6 | *.kate-swp 7 | *.kdev4 8 | .kdev_include_paths 9 | *.kdevelop.pcs 10 | *.moc 11 | *.moc.cpp 12 | *.orig 13 | *.user 14 | .*.swp 15 | .swp.* 16 | Doxyfile 17 | Makefile 18 | avail 19 | random_seed 20 | /build*/ 21 | CMakeLists.txt.user* 22 | *.unc-backup* 23 | /compile_commands.json 24 | .clangd 25 | .idea 26 | /cmake-build* 27 | .cache 28 | .directory 29 | -------------------------------------------------------------------------------- /.gitlab-ci.yml: -------------------------------------------------------------------------------- 1 | # SPDX-FileCopyrightText: 2020 Volker Krause 2 | # SPDX-License-Identifier: CC0-1.0 3 | 4 | include: 5 | - project: sysadmin/ci-utilities 6 | file: 7 | - /gitlab-templates/linux.yml 8 | - /gitlab-templates/linux-static.yml 9 | - /gitlab-templates/linux-qt6.yml 10 | - /gitlab-templates/linux-qt6-next.yml 11 | - /gitlab-templates/linux-qt6-static.yml 12 | - /gitlab-templates/freebsd.yml 13 | - /gitlab-templates/freebsd-qt6.yml 14 | - /gitlab-templates/alpine-qt6.yml 15 | -------------------------------------------------------------------------------- /.kde-ci.yml: -------------------------------------------------------------------------------- 1 | Dependencies: 2 | - 'on': ['Linux/Qt5', 'FreeBSD/Qt5'] 3 | 'require': 4 | 'frameworks/extra-cmake-modules': '@stable' 5 | 'third-party/wayland': '@latest' 6 | - 'on': ['Linux/Qt6', 'Linux/Qt6Next', 'FreeBSD/Qt6'] 7 | 'require': 8 | 'frameworks/extra-cmake-modules': '@latest-kf6' 9 | 'third-party/wayland': '@latest' 10 | 11 | Options: 12 | test-before-installing: True 13 | require-passing-tests-on: ['Linux', 'FreeBSD', 'Windows'] 14 | -------------------------------------------------------------------------------- /CMakeLists.txt: -------------------------------------------------------------------------------- 1 | # SPDX-FileCopyrightText: 2020 Aleix Pol Gonzalez 2 | # 3 | # SPDX-License-Identifier: BSD-3-Clause 4 | 5 | cmake_minimum_required(VERSION 3.5) 6 | 7 | project(PlasmaWaylandProtocols VERSION 1.18.0) 8 | 9 | include(FeatureSummary) 10 | include(CMakePackageConfigHelpers) 11 | 12 | # ECM setup 13 | find_package(ECM 5.69.0 NO_MODULE) 14 | set_package_properties(ECM PROPERTIES TYPE REQUIRED DESCRIPTION "Extra CMake Modules." URL "https://commits.kde.org/extra-cmake-modules") 15 | feature_summary(WHAT REQUIRED_PACKAGES_NOT_FOUND FATAL_ON_MISSING_REQUIRED_PACKAGES) 16 | set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH} ${CMAKE_SOURCE_DIR}/cmake/Modules) 17 | include(KDEInstallDirs) 18 | include(KDECMakeSettings) 19 | include(ECMSetupVersion) 20 | 21 | add_subdirectory(src) 22 | 23 | if (BUILD_TESTING) 24 | find_package(WaylandScanner REQUIRED) 25 | find_package(Wayland COMPONENTS Client REQUIRED) 26 | add_subdirectory(autotests) 27 | endif() 28 | 29 | # create a Config.cmake and a ConfigVersion.cmake file and install them 30 | set(CMAKECONFIG_INSTALL_DIR "${KDE_INSTALL_CMAKEPACKAGEDIR}/PlasmaWaylandProtocols") 31 | 32 | configure_package_config_file("${CMAKE_CURRENT_SOURCE_DIR}/PlasmaWaylandProtocolsConfig.cmake.in" 33 | "${CMAKE_CURRENT_BINARY_DIR}/PlasmaWaylandProtocolsConfig.cmake" 34 | INSTALL_DESTINATION ${CMAKECONFIG_INSTALL_DIR} 35 | PATH_VARS KDE_INSTALL_DATADIR 36 | ) 37 | ecm_setup_version(PROJECT VARIABLE_PREFIX PLASMA_WAYLAND_PROTOCOLS 38 | VERSION_HEADER "${CMAKE_CURRENT_BINARY_DIR}/plasma_wayland_protocols_version.h" 39 | PACKAGE_VERSION_FILE "${CMAKE_CURRENT_BINARY_DIR}/PlasmaWaylandProtocolsConfigVersion.cmake" 40 | SOVERSION 5) 41 | 42 | install(FILES "${CMAKE_CURRENT_BINARY_DIR}/PlasmaWaylandProtocolsConfig.cmake" 43 | "${CMAKE_CURRENT_BINARY_DIR}/PlasmaWaylandProtocolsConfigVersion.cmake" 44 | DESTINATION "${CMAKECONFIG_INSTALL_DIR}" 45 | COMPONENT Devel ) 46 | 47 | feature_summary(WHAT ALL FATAL_ON_MISSING_REQUIRED_PACKAGES) 48 | -------------------------------------------------------------------------------- /LICENSES/BSD-3-Clause.txt: -------------------------------------------------------------------------------- 1 | Copyright (c) . All rights reserved. 2 | 3 | Redistribution and use in source and binary forms, with or without modification, 4 | are permitted provided that the following conditions are met: 5 | 6 | 1. Redistributions of source code must retain the above copyright notice, 7 | this list of conditions and the following disclaimer. 8 | 9 | 2. Redistributions in binary form must reproduce the above copyright notice, 10 | this list of conditions and the following disclaimer in the documentation 11 | and/or other materials provided with the distribution. 12 | 13 | 3. Neither the name of the copyright holder nor the names of its contributors 14 | may be used to endorse or promote products derived from this software without 15 | specific prior written permission. 16 | 17 | THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 18 | AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 19 | IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 20 | ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE 21 | LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 22 | DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 23 | SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 24 | CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 25 | OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE 26 | USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 27 | -------------------------------------------------------------------------------- /LICENSES/CC0-1.0.txt: -------------------------------------------------------------------------------- 1 | Creative Commons Legal Code 2 | 3 | CC0 1.0 Universal 4 | 5 | CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE 6 | LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN 7 | ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS 8 | INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES 9 | REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS 10 | PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM 11 | THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED 12 | HEREUNDER. 13 | 14 | Statement of Purpose 15 | 16 | The laws of most jurisdictions throughout the world automatically confer 17 | exclusive Copyright and Related Rights (defined below) upon the creator 18 | and subsequent owner(s) (each and all, an "owner") of an original work of 19 | authorship and/or a database (each, a "Work"). 20 | 21 | Certain owners wish to permanently relinquish those rights to a Work for 22 | the purpose of contributing to a commons of creative, cultural and 23 | scientific works ("Commons") that the public can reliably and without fear 24 | of later claims of infringement build upon, modify, incorporate in other 25 | works, reuse and redistribute as freely as possible in any form whatsoever 26 | and for any purposes, including without limitation commercial purposes. 27 | These owners may contribute to the Commons to promote the ideal of a free 28 | culture and the further production of creative, cultural and scientific 29 | works, or to gain reputation or greater distribution for their Work in 30 | part through the use and efforts of others. 31 | 32 | For these and/or other purposes and motivations, and without any 33 | expectation of additional consideration or compensation, the person 34 | associating CC0 with a Work (the "Affirmer"), to the extent that he or she 35 | is an owner of Copyright and Related Rights in the Work, voluntarily 36 | elects to apply CC0 to the Work and publicly distribute the Work under its 37 | terms, with knowledge of his or her Copyright and Related Rights in the 38 | Work and the meaning and intended legal effect of CC0 on those rights. 39 | 40 | 1. Copyright and Related Rights. A Work made available under CC0 may be 41 | protected by copyright and related or neighboring rights ("Copyright and 42 | Related Rights"). Copyright and Related Rights include, but are not 43 | limited to, the following: 44 | 45 | i. the right to reproduce, adapt, distribute, perform, display, 46 | communicate, and translate a Work; 47 | ii. moral rights retained by the original author(s) and/or performer(s); 48 | iii. publicity and privacy rights pertaining to a person's image or 49 | likeness depicted in a Work; 50 | iv. rights protecting against unfair competition in regards to a Work, 51 | subject to the limitations in paragraph 4(a), below; 52 | v. rights protecting the extraction, dissemination, use and reuse of data 53 | in a Work; 54 | vi. database rights (such as those arising under Directive 96/9/EC of the 55 | European Parliament and of the Council of 11 March 1996 on the legal 56 | protection of databases, and under any national implementation 57 | thereof, including any amended or successor version of such 58 | directive); and 59 | vii. other similar, equivalent or corresponding rights throughout the 60 | world based on applicable law or treaty, and any national 61 | implementations thereof. 62 | 63 | 2. Waiver. To the greatest extent permitted by, but not in contravention 64 | of, applicable law, Affirmer hereby overtly, fully, permanently, 65 | irrevocably and unconditionally waives, abandons, and surrenders all of 66 | Affirmer's Copyright and Related Rights and associated claims and causes 67 | of action, whether now known or unknown (including existing as well as 68 | future claims and causes of action), in the Work (i) in all territories 69 | worldwide, (ii) for the maximum duration provided by applicable law or 70 | treaty (including future time extensions), (iii) in any current or future 71 | medium and for any number of copies, and (iv) for any purpose whatsoever, 72 | including without limitation commercial, advertising or promotional 73 | purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each 74 | member of the public at large and to the detriment of Affirmer's heirs and 75 | successors, fully intending that such Waiver shall not be subject to 76 | revocation, rescission, cancellation, termination, or any other legal or 77 | equitable action to disrupt the quiet enjoyment of the Work by the public 78 | as contemplated by Affirmer's express Statement of Purpose. 79 | 80 | 3. Public License Fallback. Should any part of the Waiver for any reason 81 | be judged legally invalid or ineffective under applicable law, then the 82 | Waiver shall be preserved to the maximum extent permitted taking into 83 | account Affirmer's express Statement of Purpose. In addition, to the 84 | extent the Waiver is so judged Affirmer hereby grants to each affected 85 | person a royalty-free, non transferable, non sublicensable, non exclusive, 86 | irrevocable and unconditional license to exercise Affirmer's Copyright and 87 | Related Rights in the Work (i) in all territories worldwide, (ii) for the 88 | maximum duration provided by applicable law or treaty (including future 89 | time extensions), (iii) in any current or future medium and for any number 90 | of copies, and (iv) for any purpose whatsoever, including without 91 | limitation commercial, advertising or promotional purposes (the 92 | "License"). The License shall be deemed effective as of the date CC0 was 93 | applied by Affirmer to the Work. Should any part of the License for any 94 | reason be judged legally invalid or ineffective under applicable law, such 95 | partial invalidity or ineffectiveness shall not invalidate the remainder 96 | of the License, and in such case Affirmer hereby affirms that he or she 97 | will not (i) exercise any of his or her remaining Copyright and Related 98 | Rights in the Work or (ii) assert any associated claims and causes of 99 | action with respect to the Work, in either case contrary to Affirmer's 100 | express Statement of Purpose. 101 | 102 | 4. Limitations and Disclaimers. 103 | 104 | a. No trademark or patent rights held by Affirmer are waived, abandoned, 105 | surrendered, licensed or otherwise affected by this document. 106 | b. Affirmer offers the Work as-is and makes no representations or 107 | warranties of any kind concerning the Work, express, implied, 108 | statutory or otherwise, including without limitation warranties of 109 | title, merchantability, fitness for a particular purpose, non 110 | infringement, or the absence of latent or other defects, accuracy, or 111 | the present or absence of errors, whether or not discoverable, all to 112 | the greatest extent permissible under applicable law. 113 | c. Affirmer disclaims responsibility for clearing rights of other persons 114 | that may apply to the Work or any use thereof, including without 115 | limitation any person's Copyright and Related Rights in the Work. 116 | Further, Affirmer disclaims responsibility for obtaining any necessary 117 | consents, permissions or other rights required for any use of the 118 | Work. 119 | d. Affirmer understands and acknowledges that Creative Commons is not a 120 | party to this document and has no duty or obligation with respect to 121 | this CC0 or use of the Work. 122 | -------------------------------------------------------------------------------- /LICENSES/MIT-CMU.txt: -------------------------------------------------------------------------------- 1 | By obtaining, using, and/or copying this software and/or 2 | its associated documentation, you agree that you have read, understood, and 3 | will comply with the following terms and conditions: 4 | 5 | Permission to use, copy, modify, and distribute this software and its associated 6 | documentation for any purpose and without fee is hereby granted, provided 7 | that the above copyright notice appears in all copies, and that both that 8 | copyright notice and this permission notice appear in supporting documentation, 9 | and that the name of the copyright holder not be used in advertising or publicity 10 | pertaining to distribution of the software without specific, written permission. 11 | 12 | THE COPYRIGHT HOLDER DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, 13 | INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT 14 | SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL 15 | DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM THE LOSS OF USE, DATA OR 16 | PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, 17 | ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. 18 | -------------------------------------------------------------------------------- /LICENSES/MIT.txt: -------------------------------------------------------------------------------- 1 | MIT License Copyright (c) 2 | 3 | Permission is hereby granted, free of charge, to any person obtaining a copy 4 | of this software and associated documentation files (the "Software"), to deal 5 | in the Software without restriction, including without limitation the rights 6 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 7 | copies of the Software, and to permit persons to whom the Software is furnished 8 | to do so, subject to the following conditions: 9 | 10 | The above copyright notice and this permission notice (including the next 11 | paragraph) shall be included in all copies or substantial portions of the 12 | Software. 13 | 14 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 15 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS 16 | FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS 17 | OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, 18 | WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF 19 | OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 20 | -------------------------------------------------------------------------------- /PlasmaWaylandProtocolsConfig.cmake.in: -------------------------------------------------------------------------------- 1 | # SPDX-FileCopyrightText: 2020 Aleix Pol Gonzalez 2 | # 3 | # SPDX-License-Identifier: BSD-3-Clause 4 | 5 | @PACKAGE_INIT@ 6 | 7 | include(CMakeFindDependencyMacro) 8 | 9 | set(PLASMA_WAYLAND_PROTOCOLS_DIR "@PACKAGE_KDE_INSTALL_DATADIR@/plasma-wayland-protocols") 10 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Plasma Wayland Protocols 2 | 3 | This project provides the xml files of the non-standard wayland 4 | protocols we use in Plasma. 5 | 6 | They are installed to $PREFIX/share/plasma-wayland-protocols. 7 | 8 | ## Usage 9 | You can get the directory where they're installed by using 10 | 11 | find_package(PlasmaWaylandProtocols) 12 | 13 | Then they can be accessed using `${PLASMA_WAYLAND_PROTOCOLS_DIR}`. 14 | 15 | You can learn more about such protocol files in 16 | https://wayland.freedesktop.org/docs/html/ch04.html. 17 | -------------------------------------------------------------------------------- /autotests/CMakeLists.txt: -------------------------------------------------------------------------------- 1 | # SPDX-License-Identifier: BSD-3-Clause 2 | # SPDX-FileCopyrightText: 2024 David Redondo 3 | 4 | file(GLOB PROTOCOLS CONFIGURE_DEPENDS ${PROJECT_SOURCE_DIR}/src/protocols/*.xml) 5 | 6 | foreach(PROTOCOL IN LISTS PROTOCOLS) 7 | get_filename_component(PROTOCOL_BASENAME ${PROTOCOL} NAME_WE) 8 | set(CLIENT_HEADER ${PROTOCOL_BASENAME}-client-protocol.h) 9 | set(SERVER_HEADER ${PROTOCOL_BASENAME}-server-protocol.h) 10 | set(CODE ${PROTOCOL_BASENAME}-protocol.c) 11 | add_test(NAME ${PROTOCOL_BASENAME}_client-header COMMAND Wayland::Scanner --strict client-header ${PROTOCOL} ${CLIENT_HEADER}) 12 | add_test(NAME ${PROTOCOL_BASENAME}_server-header COMMAND Wayland::Scanner --strict client-header ${PROTOCOL} ${SERVER_HEADER}) 13 | add_test(NAME ${PROTOCOL_BASENAME}_code COMMAND Wayland::Scanner --strict private-code ${PROTOCOL} ${CODE}) 14 | # fail if there is any warning from wayland-scanner, except plasma-window-managment which has preexisting issues 15 | if (NOT ${PROTOCOL_BASENAME} STREQUAL "plasma-window-management") 16 | set_tests_properties(${PROTOCOL_BASENAME}_client-header ${PROTOCOL_BASENAME}_server-header ${PROTOCOL_BASENAME}_code PROPERTIES FAIL_REGULAR_EXPRESSION ".+") 17 | endif() 18 | configure_file(build.c build-${PROTOCOL_BASENAME}.c @ONLY) 19 | add_test(NAME ${PROTOCOL_BASENAME}_build COMMAND ${CMAKE_C_COMPILER} build-${PROTOCOL_BASENAME}.c ${CODE} -I ${Wayland_INCLUDE_DIRS} -Wl,--unresolved-symbols=ignore-all) 20 | endforeach() 21 | -------------------------------------------------------------------------------- /autotests/CMakeListst.txt: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/KDE/plasma-wayland-protocols/4a75a45499a319297a1f38cf8ba3e669c9338ec6/autotests/CMakeListst.txt -------------------------------------------------------------------------------- /autotests/build.c: -------------------------------------------------------------------------------- 1 | // SPDX-License-Identifier: CC0-1.0 2 | 3 | #include "@CLIENT_HEADER@" 4 | #include "@SERVER_HEADER@" 5 | 6 | int main() 7 | { 8 | return 0; 9 | } 10 | -------------------------------------------------------------------------------- /cmake/Modules/FindWaylandProtocols.cmake: -------------------------------------------------------------------------------- 1 | #.rst: 2 | # FindWaylandProtocols 3 | # ------- 4 | # 5 | # Try to find wayland-protocols on a Unix system. 6 | # 7 | # This will define the following variables: 8 | # 9 | # ``WaylandProtocols_FOUND`` 10 | # True if (the requested version of) wayland-protocols is available 11 | # ``WaylandProtocols_VERSION`` 12 | # The version of wayland-protocols 13 | # ``WaylandProtocols_DATADIR`` 14 | # The wayland protocols data directory 15 | 16 | #============================================================================= 17 | # SPDX-FileCopyrightText: 2019 Vlad Zahorodnii 18 | # 19 | # SPDX-License-Identifier: BSD-3-Clause 20 | #============================================================================= 21 | 22 | find_package(PkgConfig) 23 | pkg_check_modules(PKG_wayland_protocols QUIET wayland-protocols) 24 | 25 | set(WaylandProtocols_VERSION ${PKG_wayland_protocols_VERSION}) 26 | pkg_get_variable(WaylandProtocols_DATADIR wayland-protocols pkgdatadir) 27 | 28 | include(FindPackageHandleStandardArgs) 29 | find_package_handle_standard_args(WaylandProtocols 30 | FOUND_VAR WaylandProtocols_FOUND 31 | REQUIRED_VARS WaylandProtocols_DATADIR 32 | VERSION_VAR WaylandProtocols_VERSION 33 | ) 34 | 35 | include(FeatureSummary) 36 | set_package_properties(WaylandProtocols PROPERTIES 37 | DESCRIPTION "Specifications of extended Wayland protocols" 38 | URL "https://wayland.freedesktop.org/" 39 | ) 40 | -------------------------------------------------------------------------------- /metainfo.yaml: -------------------------------------------------------------------------------- 1 | maintainer: 2 | description: Provides the xml files of non-standard wayland protocols used in Plasma. 3 | irc: kwin 4 | mailinglist: kwin 5 | type: integration 6 | platforms: 7 | - name: Linux 8 | - name: FreeBSD 9 | portingAid: false 10 | deprecated: false 11 | release: true 12 | cmakename: PlasmaWaylandProtocols 13 | 14 | public_lib: true 15 | -------------------------------------------------------------------------------- /src/CMakeLists.txt: -------------------------------------------------------------------------------- 1 | # SPDX-FileCopyrightText: 2020 Aleix Pol Gonzalez 2 | # 3 | # SPDX-License-Identifier: BSD-3-Clause 4 | 5 | install(FILES 6 | protocols/appmenu.xml 7 | protocols/blur.xml 8 | protocols/contrast.xml 9 | protocols/dpms.xml 10 | protocols/fake-input.xml 11 | protocols/fullscreen-shell.xml 12 | protocols/idle.xml 13 | protocols/kde-external-brightness-v1.xml 14 | protocols/kde-lockscreen-overlay-v1.xml 15 | protocols/kde-output-device-v2.xml 16 | protocols/kde-output-management-v2.xml 17 | protocols/kde-output-order-v1.xml 18 | protocols/kde-primary-output-v1.xml 19 | protocols/kde-screen-edge-v1.xml 20 | protocols/keystate.xml 21 | protocols/org-kde-plasma-virtual-desktop.xml 22 | protocols/output-management.xml 23 | protocols/outputdevice.xml 24 | protocols/plasma-shell.xml 25 | protocols/plasma-window-management.xml 26 | protocols/remote-access.xml 27 | protocols/server-decoration-palette.xml 28 | protocols/server-decoration.xml 29 | protocols/shadow.xml 30 | protocols/slide.xml 31 | protocols/surface-extension.xml 32 | protocols/text-input-unstable-v2.xml 33 | protocols/text-input.xml 34 | protocols/wayland-eglstream-controller.xml 35 | protocols/zkde-screencast-unstable-v1.xml 36 | 37 | DESTINATION ${KDE_INSTALL_DATADIR}/plasma-wayland-protocols) 38 | 39 | # Backward compatibility for previously used non-standard protocol file names 40 | # TODO KF6 remove 41 | install(FILES protocols/zkde-screencast-unstable-v1.xml RENAME screencast.xml DESTINATION ${KDE_INSTALL_DATADIR}/plasma-wayland-protocols) 42 | install(FILES protocols/org-kde-plasma-virtual-desktop.xml RENAME plasma-virtual-desktop.xml DESTINATION ${KDE_INSTALL_DATADIR}/plasma-wayland-protocols) 43 | -------------------------------------------------------------------------------- /src/protocols/TODOKF6.md: -------------------------------------------------------------------------------- 1 | # To be removed 2 | Only remove after Plasma 5 and KF 5 releases end. 3 | 4 | * fullscreen-shell.xml: It's upstream https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/master/unstable 5 | * remote-access.xml: Deprecated in favor of screencast.xml 6 | * surface-extension.xml: Deprecated in Qt, not used anymore 7 | * wayland-eglstream-controller.xml: to be removed and moved to kwin, no other component in KDE should care about this, neither others. It's not a protocol we own. 8 | * remove the legacy install name of zkde-screencast-unstable-v1 9 | -------------------------------------------------------------------------------- /src/protocols/appmenu.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 8 | 9 | 10 | This interface allows a client to link a window (or wl_surface) to an com.canonical.dbusmenu 11 | interface registered on DBus. 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | The DBus service name and object path where the appmenu interface is present 25 | The object should be registered on the session bus before sending this request. 26 | If not applicable, clients should remove this object. 27 | 28 | 29 | 30 | Set or update the service name and object path. 31 | Strings should be formatted in Latin-1 matching the relevant DBus specifications. 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | -------------------------------------------------------------------------------- /src/protocols/blur.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | -------------------------------------------------------------------------------- /src/protocols/contrast.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | enables 'frost' variant of contrast effect. 40 | 41 | 'frost' is an enhanced version of the contrast effect that 42 | uses different colour arithmetic to get backgrounds simultaneously 43 | higher in contrast and (apparent) transparency. 44 | 45 | r, g, b, a are channels from 0-255, indicating a colour to use in contrast calculation. 46 | should be based off of the "main" background colour of the surface. 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | -------------------------------------------------------------------------------- /src/protocols/dpms.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 8 | 9 | 10 | The Dpms manager allows to get a org_kde_kwin_dpms for a given wl_output. 11 | The org_kde_kwin_dpms provides the currently used VESA Display Power Management 12 | Signaling state (see https://en.wikipedia.org/wiki/VESA_Display_Power_Management_Signaling ). 13 | In addition it allows to request a state change. A compositor is not obliged to honor it 14 | and will normally automatically switch back to on state. 15 | 16 | Warning! The protocol described in this file is a desktop environment 17 | implementation detail. Regular clients must not use this protocol. 18 | Backward incompatible changes may be added without bumping the major 19 | version of the extension. 20 | 21 | 22 | 23 | Factory request to get the org_kde_kwin_dpms for a given wl_output. 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | This interface provides information about the VESA DPMS state for a wl_output. 32 | It gets created through the request get on the org_kde_kwin_dpms_manager interface. 33 | 34 | On creating the resource the server will push whether DPSM is supported for the output, 35 | the currently used DPMS state and notifies the client through the done event once all 36 | states are pushed. Whenever a state changes the set of changes is committed with the 37 | done event. 38 | 39 | 40 | 41 | This event gets pushed on binding the resource and indicates whether the wl_output 42 | supports DPMS. There are operation modes of a Wayland server where DPMS might not 43 | make sense (e.g. nested compositors). 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | This mode gets pushed on binding the resource and provides the currently used 56 | DPMS mode. It also gets pushed if DPMS is not supported for the wl_output, in that 57 | case the value will be On. 58 | 59 | The event is also pushed whenever the state changes. 60 | 61 | 62 | 63 | 64 | 65 | This event gets pushed on binding the resource once all other states are pushed. 66 | 67 | In addition it gets pushed whenever a state changes to tell the client that all 68 | state changes have been pushed. 69 | 70 | 71 | 72 | 73 | Requests that the compositor puts the wl_output into the passed mode. The compositor 74 | is not obliged to change the state. In addition the compositor might leave the mode 75 | whenever it seems suitable. E.g. the compositor might return to On state on user input. 76 | 77 | The client should not assume that the mode changed after requesting a new mode. 78 | Instead the client should listen for the mode event. 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | -------------------------------------------------------------------------------- /src/protocols/fake-input.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 8 | 9 | 10 | This interface allows other processes to provide fake input events. 11 | Purpose is on the one hand side to provide testing facilities like XTest on X11. 12 | But also to support use case like kdeconnect's mouse pad interface. 13 | 14 | A compositor should not trust the input received from this interface. 15 | Clients should not expect that the compositor honors the requests from this 16 | interface. 17 | 18 | Warning! The protocol described in this file is a desktop environment 19 | implementation detail. Regular clients must not use this protocol. 20 | Backward incompatible changes may be added without bumping the major 21 | version of the extension. 22 | 23 | 24 | 25 | A client should use this request to tell the compositor why it wants to 26 | use this interface. The compositor might use the information to decide 27 | whether it wants to grant the request. The data might also be passed to 28 | the user to decide whether the application should get granted access to 29 | this very privileged interface. 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | A client should use this request to send touch down event at specific 49 | coordinates. 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | A client should use this request to send touch motion to specific position. 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | A client should use this request to send touch up event. 66 | 67 | 68 | 69 | 70 | 71 | A client should use this request to cancel the current 72 | touch event. 73 | 74 | 75 | 76 | 77 | A client should use this request to send touch frame event. 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | -------------------------------------------------------------------------------- /src/protocols/fullscreen-shell.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Displays a single surface per output. 5 | 6 | This interface provides a mechanism for a single client to display 7 | simple full-screen surfaces. While there technically may be multiple 8 | clients bound to this interface, only one of those clients should be 9 | shown at a time. 10 | 11 | To present a surface, the client uses either the present_surface or 12 | present_surface_for_mode requests. Presenting a surface takes effect 13 | on the next wl_surface.commit. See the individual requests for 14 | details about scaling and mode switches. 15 | 16 | The client can have at most one surface per output at any time. 17 | Requesting a surface be presented on an output that already has a 18 | surface replaces the previously presented surface. Presenting a null 19 | surface removes its content and effectively disables the output. 20 | Exactly what happens when an output is "disabled" is 21 | compositor-specific. The same surface may be presented on multiple 22 | outputs simultaneously. 23 | 24 | Once a surface is presented on an output, it stays on that output 25 | until either the client removes it or the compositor destroys the 26 | output. This way, the client can update the output's contents by 27 | simply attaching a new buffer. 28 | 29 | 30 | 31 | 32 | Release the binding from the wl_fullscreen_shell interface 33 | 34 | This destroys the server-side object and frees this binding. If 35 | the client binds to wl_fullscreen_shell multiple times, it may wish 36 | to free some of those bindings. 37 | 38 | 39 | 40 | 41 | 42 | Various capabilities that can be advertised by the compositor. They 43 | are advertised one-at-a-time when the wl_fullscreen_shell interface is 44 | bound. See the wl_fullscreen_shell.capability event for more details. 45 | 46 | ARBITRARY_MODE: 47 | This is a hint to the client that indicates that the compositor is 48 | capable of setting practically any mode on its outputs. If this 49 | capability is provided, wl_fullscreen_shell.present_surface_for_mode 50 | will almost never fail and clients should feel free to set whatever 51 | mode they like. If the compositor does not advertise this, it may 52 | still support some modes that are not advertised through wl_global.mode 53 | but it is less likely. 54 | 55 | CURSOR_PLANE: 56 | This is a hint to the client that indicates that the compositor can 57 | handle a cursor surface from the client without actually compositing. 58 | This may be because of a hardware cursor plane or some other mechanism. 59 | If the compositor does not advertise this capability then setting 60 | wl_pointer.cursor may degrade performance or be ignored entirely. If 61 | CURSOR_PLANE is not advertised, it is recommended that the client draw 62 | its own cursor and set wl_pointer.cursor(NULL). 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | Advertises a single capability of the compositor. 71 | 72 | When the wl_fullscreen_shell interface is bound, this event is emitted 73 | once for each capability advertised. Valid capabilities are given by 74 | the wl_fullscreen_shell.capability enum. If clients want to take 75 | advantage of any of these capabilities, they should use a 76 | wl_display.sync request immediately after binding to ensure that they 77 | receive all the capability events. 78 | 79 | 80 | 81 | 82 | 83 | 84 | Hints to indicate to the compositor how to deal with a conflict 85 | between the dimensions of the surface and the dimensions of the 86 | output. The compositor is free to ignore this parameter. 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | Present a surface on the given output. 98 | 99 | If the output is null, the compositor will present the surface on 100 | whatever display (or displays) it thinks best. In particular, this 101 | may replace any or all surfaces currently presented so it should 102 | not be used in combination with placing surfaces on specific 103 | outputs. 104 | 105 | The method parameter is a hint to the compositor for how the surface 106 | is to be presented. In particular, it tells the compostior how to 107 | handle a size mismatch between the presented surface and the 108 | output. The compositor is free to ignore this parameter. 109 | 110 | The "zoom", "zoom_crop", and "stretch" methods imply a scaling 111 | operation on the surface. This will override any kind of output 112 | scaling, so the buffer_scale property of the surface is effectively 113 | ignored. 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | Presents a surface on the given output for a particular mode. 123 | 124 | If the current size of the output differs from that of the surface, 125 | the compositor will attempt to change the size of the output to 126 | match the surface. The result of the mode-switch operation will be 127 | returned via the provided wl_fullscreen_shell_mode_feedback object. 128 | 129 | If the current output mode matches the one requested or if the 130 | compositor successfully switches the mode to match the surface, 131 | then the mode_successful event will be sent and the output will 132 | contain the contents of the given surface. If the compositor 133 | cannot match the output size to the surface size, the mode_failed 134 | will be sent and the output will contain the contents of the 135 | previously presented surface (if any). If another surface is 136 | presented on the given output before either of these has a chance 137 | to happen, the present_cancelled event will be sent. 138 | 139 | Due to race conditions and other issues unknown to the client, no 140 | mode-switch operation is guaranteed to succeed. However, if the 141 | mode is one advertised by wl_output.mode or if the compositor 142 | advertises the ARBITRARY_MODES capability, then the client should 143 | expect that the mode-switch operation will usually succeed. 144 | 145 | If the size of the presented surface changes, the resulting output 146 | is undefined. The compositor may attempt to change the output mode 147 | to compensate. However, there is no guarantee that a suitable mode 148 | will be found and the client has no way to be notified of success 149 | or failure. 150 | 151 | The framerate parameter specifies the desired framerate for the 152 | output in mHz. The compositor is free to ignore this parameter. A 153 | value of 0 indicates that the client has no preference. 154 | 155 | If the value of wl_output.scale differs from wl_surface.buffer_scale, 156 | then the compositor may choose a mode that matches either the buffer 157 | size or the surface size. In either case, the surface will fill the 158 | output. 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | These errors can be emitted in response to wl_fullscreen_shell requests 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | This event indicates that the attempted mode switch operation was 178 | successful. A surface of the size requested in the mode switch 179 | will fill the output without scaling. 180 | 181 | Upon receiving this event, the client should destroy the 182 | wl_fullscreen_shell_mode_feedback object. 183 | 184 | 185 | 186 | 187 | This event indicates that the attempted mode switch operation 188 | failed. This may be because the requested output mode is not 189 | possible or it may mean that the compositor does not want to allow it. 190 | 191 | Upon receiving this event, the client should destroy the 192 | wl_fullscreen_shell_mode_feedback object. 193 | 194 | 195 | 196 | 197 | This event indicates that the attempted mode switch operation was 198 | cancelled. Most likely this is because the client requested a 199 | second mode switch before the first one completed. 200 | 201 | Upon receiving this event, the client should destroy the 202 | wl_fullscreen_shell_mode_feedback object. 203 | 204 | 205 | 206 | 207 | -------------------------------------------------------------------------------- /src/protocols/idle.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 8 | 9 | 10 | This interface allows to monitor user idle time on a given seat. The interface 11 | allows to register timers which trigger after no user activity was registered 12 | on the seat for a given interval. It notifies when user activity resumes. 13 | 14 | This is useful for applications wanting to perform actions when the user is not 15 | interacting with the system, e.g. chat applications setting the user as away, power 16 | management features to dim screen, etc.. 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | -------------------------------------------------------------------------------- /src/protocols/kde-external-brightness-v1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 6 | SPDX-License-Identifier: MIT-CMU 7 | ]]> 8 | 9 | 10 | 11 | Some brightness control mechanisms are somewhat unstable, or require root 12 | privileges, so putting them inside of the compositor is not desired. 13 | This protocol is for outsourcing the actual brightness-setting to a 14 | process outside of the compositor. 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | After creating this object, the client should issue all relevant setup requests 30 | (set_internal, set_edid, set_max_brightness, optionally set_observed_brightness) 31 | and finish the sequence with commit. 32 | Afterwards, for each change in values, the client must call commit again. 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | The client must ensure that if the brightness level changes due to external factors, 61 | that it either overwrites those changes with what the compositor last requested, 62 | or commit again with set_observed_brightness specifying the changed brightness. 63 | 64 | 65 | 66 | 67 | 68 | 69 | The client can set this to notify the compositor of the device's initial brightness. 70 | It can also set this again after the initial commit to notify the compositor that 71 | the brightness level has changed due to external factors. 72 | The compositor is free to use or ignore this value as it sees fit. 73 | 74 | 75 | 76 | 77 | 78 | 79 | The compositor can use this information to ignore this object if its commands 80 | expose monitor issues. The compositor may also reduce the amount of brightness 81 | requests given potentially slow response times and concerns about monitor EEPROM 82 | longevity/wear-out. 83 | 84 | 85 | 86 | 87 | 88 | 89 | -------------------------------------------------------------------------------- /src/protocols/kde-lockscreen-overlay-v1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 6 | SPDX-License-Identifier: LGPL-2.1-or-later 7 | ]]> 8 | 9 | 10 | 11 | Allows a client to request a surface to be visible when the system is locked. 12 | 13 | This is meant to be used for specific high urgency cases like phone calls or alarms. 14 | 15 | Warning! The protocol described in this file is a desktop environment 16 | implementation detail. Regular clients must not use this protocol. 17 | Backward incompatible changes may be added without bumping the major 18 | version of the extension. 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | Informs the compositor that the surface could be shown when the screen is locked. This request should be called while the surface is unmapped. 28 | 29 | 30 | 31 | 32 | 33 | 34 | This won't affect the surface previously marked with the allow request. 35 | 36 | 37 | 38 | 39 | -------------------------------------------------------------------------------- /src/protocols/kde-output-management-v2.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 8 | SPDX-FileCopyrightText: 2021 Méven Car 9 | SPDX-FileCopyrightText: 2023 Xaver Hugl 10 | 11 | SPDX-License-Identifier: MIT-CMU 12 | ]]> 13 | 14 | 15 | 16 | This interface enables clients to set properties of output devices for screen 17 | configuration purposes via the server. To this end output devices are referenced 18 | by global kde_output_device_v2 objects. 19 | 20 | outputmanagement (wl_global) 21 | -------------------------- 22 | request: 23 | * create_configuration -> outputconfiguration (wl_resource) 24 | 25 | outputconfiguration (wl_resource) 26 | -------------------------- 27 | requests: 28 | * enable(outputdevice, bool) 29 | * mode(outputdevice, mode) 30 | * transformation(outputdevice, flag) 31 | * position(outputdevice, x, y) 32 | * apply 33 | 34 | events: 35 | * applied 36 | * failed 37 | 38 | The server registers one outputmanagement object as a global object. In order 39 | to configure outputs a client requests create_configuration, which provides a 40 | resource referencing an outputconfiguration for one-time configuration. That 41 | way the server knows which requests belong together and can group them by that. 42 | 43 | On the outputconfiguration object the client calls for each output whether the 44 | output should be enabled, which mode should be set (by referencing the mode from 45 | the list of announced modes) and the output's global position. Once all outputs 46 | are configured that way, the client calls apply. 47 | At that point and not earlier the server should try to apply the configuration. 48 | If this succeeds the server emits the applied signal, otherwise the failed 49 | signal, such that the configuring client is noticed about the success of its 50 | configuration request. 51 | 52 | Through this design the interface enables atomic output configuration changes if 53 | internally supported by the server. 54 | 55 | Warning! The protocol described in this file is a desktop environment implementation 56 | detail. Regular clients must not use this protocol. Backward incompatible 57 | changes may be added without bumping the major version of the extension. 58 | 59 | 60 | 61 | Request an outputconfiguration object through which the client can configure 62 | output devices. 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | outputconfiguration is a client-specific resource that can be used to ask 72 | the server to apply changes to available output devices. 73 | 74 | The client receives a list of output devices from the registry. When it wants 75 | to apply new settings, it creates a configuration object from the 76 | outputmanagement global, writes changes through this object's enable, scale, 77 | transform and mode calls. It then asks the server to apply these settings in 78 | an atomic fashion, for example through Linux' DRM interface. 79 | 80 | The server signals back whether the new settings have applied successfully 81 | or failed to apply. outputdevice objects are updated after the changes have been 82 | applied to the hardware and before the server side sends the applied event. 83 | 84 | 85 | 86 | 87 | These error can be emitted in response to kde_output_configuration_v2 requests. 88 | 89 | 90 | 91 | 92 | 93 | 94 | Mark the output as enabled or disabled. 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | Sets the mode for a given output. 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | Sets the transformation for a given output. 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | Sets the position for this output device. (x,y) describe the top-left corner 119 | of the output in global space, whereby the origin (0,0) of the global space 120 | has to be aligned with the top-left corner of the most left and in case this 121 | does not define a single one the top output. 122 | 123 | There may be no gaps or overlaps between outputs, i.e. the outputs are 124 | stacked horizontally, vertically, or both on each other. 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | Sets the scaling factor for this output device. 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | Asks the server to apply property changes requested through this outputconfiguration 142 | object to all outputs on the server side. 143 | 144 | The output configuration can be applied only once. The already_applied protocol error 145 | will be posted if the apply request is called the second time. 146 | 147 | 148 | 149 | 150 | 151 | Sent after the server has successfully applied the changes. 152 | . 153 | 154 | 155 | 156 | 157 | 158 | Sent if the server rejects the changes or failed to apply them. 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | Set the overscan value of this output device with a value in percent. 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | Describes when the compositor may employ variable refresh rate 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | Set what policy the compositor should employ regarding its use of 186 | variable refresh rate. 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | Whether this output should use full or limited rgb. 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | Whether full or limited color range should be used 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | The order of outputs can be used to assign desktop environment components to a specific screen, 217 | see kde_output_order_v1 for details. The priority is 1-based for outputs that will be enabled after 218 | this changeset is applied, all outputs that are disabled need to have the index set to zero. 219 | 220 | 221 | 222 | 223 | 224 | 225 | 226 | Sets whether or not the output should be set to HDR mode. 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | Sets the brightness of standard dynamic range content in nits. Only has an effect while the output is in HDR mode. 235 | Note that while the value is in nits, that doesn't necessarily translate to the same brightness on the screen. 236 | 237 | 238 | 239 | 240 | 241 | 242 | 243 | Whether or not the output should use a wide color gamut 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | This can be used to provide the colors users assume sRGB applications should have based on the 279 | default experience on many modern sRGB screens. 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | 298 | 299 | 300 | Set the brightness modifier of the output. It doesn't specify 301 | any absolute values, but is merely a multiplier on top of other 302 | brightness values, like sdr_brightness and brightness_metadata. 303 | 0 is the minimum brightness (not completely dark) and 10000 is 304 | the maximum brightness. 305 | This is supported while HDR is active in versions 8 and below, 306 | or when the device supports the "brightness" capability in 307 | versions 9 and above. 308 | 309 | 310 | 311 | 312 | 313 | 314 | 315 | The compositor can do a lot of things that trade between 316 | performance, power and color accuracy. This setting describes 317 | a high level preference from the user about in which direction 318 | that tradeoff should be made. 319 | 320 | 321 | 322 | 323 | 324 | 325 | 326 | 327 | 328 | 329 | 330 | 331 | 332 | Set the dimming multiplier of the output. This is similar to the 333 | brightness setting, except it's meant to be a temporary setting 334 | only, not persistent and may be implemented differently depending 335 | on the display. 336 | 0 is the minimum dimming factor (not completely dark) and 10000 337 | means the output is not dimmed. 338 | 339 | This is supported only when the "brightness" capability is 340 | also supported. 341 | 342 | 343 | 344 | 345 | 346 | 347 | 348 | Describes why applying the output configuration failed. Is only 349 | sent before the failure event. 350 | 351 | 352 | 353 | 354 | 355 | 356 | Set the source output that the outputdevice should mirror its 357 | viewport from. 358 | 359 | 360 | 361 | 362 | 363 | 364 | 365 | 366 | 367 | 368 | 369 | 370 | 371 | This limits the amount of bits per color that are sent to the display. 372 | 373 | 374 | 375 | 376 | 377 | 378 | 379 | 380 | 381 | 382 | 383 | 384 | 385 | When EDR is enabled, the compositor may increase the backlight beyond 386 | the user-specified setting, in order to present HDR content on displays 387 | without native HDR support. 388 | This will usually result in better visuals, but also increases battery 389 | usage. 390 | 391 | 392 | 393 | 394 | 395 | 396 | -------------------------------------------------------------------------------- /src/protocols/kde-output-order-v1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 6 | SPDX-License-Identifier: MIT-CMU 7 | ]]> 8 | 9 | 10 | 11 | Announce the order in which desktop environment components should be placed on outputs. 12 | The compositor will send the list of outputs when the global is bound and whenever there is a change. 13 | 14 | Warning! The protocol described in this file is a desktop environment 15 | implementation detail. Regular clients must not use this protocol. 16 | Backward incompatible changes may be added without bumping the major 17 | version of the extension. 18 | 19 | 20 | 21 | 22 | Specifies the output identified by their wl_output.name. 23 | 24 | 25 | 26 | 27 | 28 | 29 | Specifies that the output list is complete. On the next output event, a new list begins. 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | -------------------------------------------------------------------------------- /src/protocols/kde-primary-output-v1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 6 | SPDX-License-Identifier: MIT-CMU 7 | ]]> 8 | 9 | 10 | 11 | Protocol for telling which is the primary display among the selection 12 | of enabled outputs. 13 | 14 | Warning! The protocol described in this file is a desktop environment 15 | implementation detail. Regular clients must not use this protocol. 16 | Backward incompatible changes may be added without bumping the major 17 | version of the extension. 18 | 19 | 20 | 21 | 22 | Specifies which output is the primary one identified by their uuid. See kde_output_device_v2 uuid event for more information about it. 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | -------------------------------------------------------------------------------- /src/protocols/kde-screen-edge-v1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | SPDX-FileCopyrightText: 2023 Vlad Zahorodnii 5 | 6 | SPDX-License-Identifier: MIT-CMU 7 | 8 | 9 | 10 | 11 | This interface allows clients to associate actions with screen edges. For 12 | example, showing a surface by moving the pointer to a screen edge. 13 | 14 | Potential ways to trigger the screen edge are subject to compositor 15 | policies. As an example, the compositor may consider the screen edge to be 16 | triggered if the pointer hits its associated screen border. Other ways may 17 | include using touchscreen or touchpad gestures. 18 | 19 | Warning! The protocol described in this file is a desktop environment 20 | implementation detail. Regular clients must not use this protocol. 21 | Backward incompatible changes may be added without bumping the major 22 | version of the extension. 23 | 24 | 25 | 26 | 28 | 30 | 32 | 33 | 34 | 35 | 36 | Destroy the screen edge manager. This doesn't destroy objects created 37 | with this manager. 38 | 39 | 40 | 41 | 42 | 43 | These values describe possible screen borders. 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | Create a new auto hide screen edge object associated with the specified 54 | surface and the border. 55 | 56 | Creating a kde_auto_hide_screen_edge_v1 object does not change the 57 | visibility of the surface. The kde_auto_hide_screen_edge_v1.activate 58 | request must be issued in order to hide the surface. 59 | 60 | The "border" argument must be a valid enum entry, otherwise the 61 | invalid_border protocol error is raised. 62 | 63 | The invalid_role protocol error will be raised if the specified surface 64 | does not have layer_surface role. 65 | 66 | 68 | 70 | 72 | 73 | 74 | 75 | 76 | 77 | The auto hide screen edge object allows to hide the surface and make it 78 | visible by triggering the screen edge. The screen edge is inactive and 79 | the surface is visible by default. 80 | 81 | This interface can be used to implement user interface elements such as 82 | auto-hide panels or docks. 83 | 84 | kde_auto_hide_screen_edge_v1.activate activates the screen edge and makes 85 | the surface hidden. The surface can be made visible by triggering the 86 | screen edge or calling kde_auto_hide_screen_edge_v1.deactivate. 87 | 88 | If the screen edge has been triggered, it won't be re-activated again. 89 | Another kde_auto_hide_screen_edge_v1.activate request must be made by the 90 | client to activate the screen edge. 91 | 92 | 93 | 94 | 95 | Destroy the auto hide screen edge object. If the screen edge is active, 96 | it will be deactivated and the surface will be made visible. 97 | 98 | 99 | 100 | 101 | 102 | Deactivate the screen edge. The surface will be made visible. 103 | 104 | 105 | 106 | 107 | 108 | Activate the screen edge. The surface will be hidden until the screen 109 | edge is triggered. 110 | 111 | 112 | 113 | 114 | -------------------------------------------------------------------------------- /src/protocols/keystate.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 6 | SPDX-License-Identifier: LGPL-2.1-or-later 7 | ]]> 8 | 9 | 10 | 11 | Keeps track of the states of the different keys that have a state attached to it. 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | -------------------------------------------------------------------------------- /src/protocols/org-kde-plasma-virtual-desktop.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 8 | 9 | 10 | 11 | 12 | Given the id of a particular virtual desktop, get the corresponding org_kde_plasma_virtual_desktop which represents only the desktop with that id. 13 | 14 | Warning! The protocol described in this file is a desktop environment 15 | implementation detail. Regular clients must not use this protocol. 16 | Backward incompatible changes may be added without bumping the major 17 | version of the extension. 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | Ask the server to create a new virtual desktop, and position it at a specified position. If the position is zero or less, it will be positioned at the beginning, if the position is the count or more, it will be positioned at the end. 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | Ask the server to get rid of a virtual desktop, the server may or may not acconsent to the request. 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | This event is sent after all other properties has been 53 | sent after binding to the desktop manager object and after any 54 | other property changes done after that. This allows 55 | changes to the org_kde_plasma_virtual_desktop_management properties to be seen as 56 | atomic, even if they happen via multiple events. 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | Request the server to set the status of this desktop to active: The server is free to consent or deny the request. This will be the new "current" virtual desktop of the system. 70 | 71 | 72 | 73 | 74 | 75 | The format of the id is decided by the compositor implementation. A desktop id univocally identifies a virtual desktop and must be guaranteed to never exist two desktops with the same id. The format of the string id is up to the server implementation. 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | The desktop will be the new "current" desktop of the system. The server may support either one virtual desktop active at a time, or other combinations such as one virtual desktop active per screen. 87 | Windows associated to this virtual desktop will be shown. 88 | 89 | 90 | 91 | 92 | 93 | Windows that were associated only to this desktop will be hidden. 94 | 95 | 96 | 97 | 98 | 99 | This event is sent after all other properties has been 100 | sent after binding to the desktop object and after any 101 | other property changes done after that. This allows 102 | changes to the org_kde_plasma_virtual_desktop properties to be seen as 103 | atomic, even if they happen via multiple events. 104 | 105 | 106 | 107 | 108 | 109 | This virtual desktop has just been removed by the server: 110 | All windows will lose the association to this desktop. 111 | 112 | 113 | 114 | 115 | 116 | -------------------------------------------------------------------------------- /src/protocols/output-management.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 8 | 9 | SPDX-License-Identifier: MIT-CMU 10 | ]]> 11 | 12 | 13 | 14 | This interface enables clients to set properties of output devices for screen 15 | configuration purposes via the server. To this end output devices are referenced 16 | by global org_kde_kwin_outputdevice objects. 17 | 18 | outputmanagement (wl_global) 19 | -------------------------- 20 | request: 21 | * create_configuration -> outputconfiguration (wl_resource) 22 | 23 | outputconfiguration (wl_resource) 24 | -------------------------- 25 | requests: 26 | * enable(outputdevice, bool) 27 | * mode(outputdevice, mode_id) 28 | * transformation(outputdevice, flag) 29 | * position(outputdevice, x, y) 30 | * apply 31 | 32 | events: 33 | * applied 34 | * failed 35 | 36 | The server registers one outputmanagement object as a global object. In order 37 | to configure outputs a client requests create_configuration, which provides a 38 | resource referencing an outputconfiguration for one-time configuration. That 39 | way the server knows which requests belong together and can group them by that. 40 | 41 | On the outputconfiguration object the client calls for each output whether the 42 | output should be enabled, which mode should be set (by referencing the mode from 43 | the list of announced modes) and the output's global position. Once all outputs 44 | are configured that way, the client calls apply. 45 | At that point and not earlier the server should try to apply the configuration. 46 | If this succeeds the server emits the applied signal, otherwise the failed 47 | signal, such that the configuring client is noticed about the success of its 48 | configuration request. 49 | 50 | Through this design the interface enables atomic output configuration changes if 51 | internally supported by the server. 52 | 53 | 54 | 55 | 56 | Request an outputconfiguration object through which the client can configure 57 | output devices. 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | outputconfiguration is a client-specific resource that can be used to ask 67 | the server to apply changes to available output devices. 68 | 69 | The client receives a list of output devices from the registry. When it wants 70 | to apply new settings, it creates a configuration object from the 71 | outputmanagement global, writes changes through this object's enable, scale, 72 | transform and mode calls. It then asks the server to apply these settings in 73 | an atomic fashion, for example through Linux' DRM interface. 74 | 75 | The server signals back whether the new settings have applied successfully 76 | or failed to apply. outputdevice objects are updated after the changes have been 77 | applied to the hardware and before the server side sends the applied event. 78 | 79 | 80 | 81 | 82 | Mark the output as enabled or disabled. 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | Sets the mode for a given output by its mode size (width and height) and refresh rate. 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | Sets the transformation for a given output. 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | Sets the position for this output device. (x,y) describe the top-left corner 107 | of the output in global space, whereby the origin (0,0) of the global space 108 | has to be aligned with the top-left corner of the most left and in case this 109 | does not define a single one the top output. 110 | 111 | There may be no gaps or overlaps between outputs, i.e. the outputs are 112 | stacked horizontally, vertically, or both on each other. 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | Sets the scaling factor for this output device. 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | Asks the server to apply property changes requested through this outputconfiguration 130 | object to all outputs on the server side. 131 | 132 | 133 | 134 | 135 | 136 | Sent after the server has successfully applied the changes. 137 | . 138 | 139 | 140 | 141 | 142 | 143 | Sent if the server rejects the changes or failed to apply them. 144 | 145 | 146 | 147 | 148 | 149 | Sets the scaling factor for this output device. 150 | Sending both scale and scalef is undefined. 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | Set color curves of output devices through RGB color ramps. Allows color 159 | correction of output device from user space. 160 | 161 | These are the raw values. A compositor might opt to adjust these values 162 | internally, for example to shift color temperature at night. 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | Set the overscan value of this output device with a value in percent. 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | Describes when the compositor may employ variable refresh rate 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | Set what policy the compositor should employ regarding its use of 194 | variable refresh rate. 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | -------------------------------------------------------------------------------- /src/protocols/outputdevice.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 8 | 9 | SPDX-License-Identifier: MIT-CMU 10 | ]]> 11 | 12 | 13 | 14 | 15 | An outputdevice describes a display device available to the compositor. 16 | outputdevice is similar to wl_output, but focuses on output 17 | configuration management. 18 | 19 | A client can query all global outputdevice objects to enlist all 20 | available display devices, even those that may currently not be 21 | represented by the compositor as a wl_output. 22 | 23 | The client sends configuration changes to the server through the 24 | outputconfiguration interface, and the server applies the configuration 25 | changes to the hardware and signals changes to the outputdevices 26 | accordingly. 27 | 28 | This object is published as global during start up for every available 29 | display devices, or when one later becomes available, for example by 30 | being hotplugged via a physical connector. 31 | 32 | 33 | 34 | 35 | This enumeration describes how the physical pixels on an output are 36 | laid out. 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | This describes the transform, that a compositor will apply to a 49 | surface to compensate for the rotation or mirroring of an 50 | output device. 51 | 52 | The flipped values correspond to an initial flip around a 53 | vertical axis followed by rotation. 54 | 55 | The purpose is mainly to allow clients to render accordingly and 56 | tell the compositor, so that for fullscreen surfaces, the 57 | compositor is still able to scan out directly client surfaces. 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | The geometry event describes geometric properties of the output. 73 | The event is sent when binding to the output object and whenever 74 | any of the properties change. 75 | 76 | 78 | 80 | 82 | 84 | 86 | 88 | 90 | 92 | 93 | 94 | 95 | 96 | These flags describe properties of an output mode. They are 97 | used in the flags bitfield of the mode event. 98 | 99 | 101 | 103 | 104 | 105 | 106 | 107 | The mode event describes an available mode for the output. 108 | 109 | When the client binds to the outputdevice object, the server sends this 110 | event once for every available mode the outputdevice can be operated by. 111 | 112 | There will always be at least one event sent out on initial binding, 113 | which represents the current mode. 114 | 115 | Later on if an output changes its mode the event is sent again, whereby 116 | this event represents the mode that has now become current. In other 117 | words, the current mode is always represented by the latest event sent 118 | with the current flag set. 119 | 120 | The size of a mode is given in physical hardware units of the output device. 121 | This is not necessarily the same as the output size in the global compositor 122 | space. For instance, the output may be scaled, as described in 123 | org_kde_kwin_outputdevice.scale, or transformed, as described in 124 | org_kde_kwin_outputdevice.transform. 125 | 126 | The id can be used to refer to a mode when calling set_mode on an 127 | org_kde_kwin_outputconfiguration object. 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | This event is sent after all other properties have been 139 | sent on binding to the output object as well as after any 140 | other output property change have been applied later on. 141 | This allows to see changes to the output properties as atomic, 142 | even if multiple events successively announce them. 143 | 144 | 145 | 146 | 147 | 148 | This event contains scaling geometry information 149 | that is not in the geometry event. It may be sent after 150 | binding the output object or if the output scale changes 151 | later. If it is not sent, the client should assume a 152 | scale of 1. 153 | 154 | A scale larger than 1 means that the compositor will 155 | automatically scale surface buffers by this amount 156 | when rendering. This is used for high resolution 157 | displays where applications rendering at the native 158 | resolution would be too small to be legible. 159 | 160 | It is intended that scaling aware clients track the 161 | current output of a surface, and if it is on a scaled 162 | output it should use wl_surface.set_buffer_scale with 163 | the scale of the output. That way the compositor can 164 | avoid scaling the surface, and the client can supply 165 | a higher detail image. 166 | 167 | 168 | 169 | 170 | 171 | 172 | The edid event encapsulates the EDID data for the outputdevice. 173 | 174 | The event is sent when binding to the output object. The EDID 175 | data may be empty, in which case this event is sent anyway. 176 | If the EDID information is empty, you can fall back to the name 177 | et al. properties of the outputdevice. 178 | 179 | 180 | 181 | 182 | 183 | 184 | Describes whether a device is enabled, i.e. device is used to 185 | display content by the compositor. This wraps a boolean around 186 | an int to avoid a boolean trap. 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | The enabled event notifies whether this output is currently 195 | enabled and used for displaying content by the server. 196 | The event is sent when binding to the output object and 197 | whenever later on an output changes its state by becoming 198 | enabled or disabled. 199 | 200 | 201 | 202 | 203 | 204 | 205 | The uuid can be used to identify the output. It's controlled by 206 | the server entirely. The server should make sure the uuid is 207 | persistent across restarts. An empty uuid is considered invalid. 208 | 209 | 210 | 211 | 212 | 213 | 214 | This event contains scaling geometry information 215 | that is not in the geometry event. It may be sent after 216 | binding the output object or if the output scale changes 217 | later. If it is not sent, the client should assume a 218 | scale of 1. 219 | 220 | A scale larger than 1 means that the compositor will 221 | automatically scale surface buffers by this amount 222 | when rendering. This is used for high resolution 223 | displays where applications rendering at the native 224 | resolution would be too small to be legible. 225 | 226 | It is intended that scaling aware clients track the 227 | current output of a surface, and if it is on a scaled 228 | output it should use wl_surface.set_buffer_scale with 229 | the scale of the output. That way the compositor can 230 | avoid scaling the surface, and the client can supply 231 | a higher detail image. 232 | 233 | wl_output will keep the output scale as an integer. In every situation except 234 | configuring the window manager you want to use that. 235 | 236 | 237 | 238 | 239 | 240 | 241 | Describes the color intensity profile of the output. 242 | Commonly used for gamma/color correction. 243 | 244 | The array contains all color ramp values of the output. 245 | For example on 8bit screens there are 256 of them. 246 | 247 | The array elements are unsigned 16bit integers. 248 | 249 | 251 | 253 | 255 | 256 | 257 | 258 | 259 | Serial ID of the monitor, sent on startup before the first done event. 260 | 261 | 263 | 264 | 265 | 266 | EISA ID of the monitor, sent on startup before the first done event. 267 | 268 | 270 | 271 | 272 | 273 | 274 | Describes what capabilities this device has. 275 | 276 | 278 | 280 | 281 | 282 | 283 | 284 | What capabilities this device has, sent on startup before the first 285 | done event. 286 | 287 | 288 | 289 | 290 | 291 | 292 | Overscan value of the monitor in percent, sent on startup before the 293 | first done event. 294 | 295 | 297 | 298 | 299 | 300 | 301 | Describes when the compositor may employ variable refresh rate 302 | 303 | 304 | 305 | 306 | 307 | 308 | 309 | 310 | What policy the compositor will employ regarding its use of variable 311 | refresh rate. 312 | 313 | 314 | 315 | 316 | 317 | 318 | 319 | 320 | 321 | -------------------------------------------------------------------------------- /src/protocols/plasma-shell.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 8 | 9 | 10 | 11 | This interface is used by KF5 powered Wayland shells to communicate with 12 | the compositor and can only be bound one time. 13 | 14 | Warning! The protocol described in this file is a desktop environment 15 | implementation detail. Regular clients must not use this protocol. 16 | Backward incompatible changes may be added without bumping the major 17 | version of the extension. 18 | 19 | 20 | 21 | 22 | 23 | 24 | Create a shell surface for an existing surface. 25 | 26 | Only one shell surface can be associated with a given 27 | surface. 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | An interface that may be implemented by a wl_surface, for 37 | implementations that provide the shell user interface. 38 | 39 | It provides requests to set surface roles, assign an output 40 | or set the position in output coordinates. 41 | 42 | On the server side the object is automatically destroyed when 43 | the related wl_surface is destroyed. On client side, 44 | org_kde_plasma_surface.destroy() must be called before 45 | destroying the wl_surface object. 46 | 47 | 48 | 49 | 50 | 51 | 52 | The org_kde_plasma_surface interface is removed from the 53 | wl_surface object that was turned into a shell surface with the 54 | org_kde_plasma_shell.get_surface request. 55 | The shell surface role is lost and wl_surface is unmapped. 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | Assign an output to this shell surface. 64 | The compositor will use this information to set the position 65 | when org_kde_plasma_surface.set_position request is 66 | called. 67 | 68 | 69 | 70 | 71 | 72 | 73 | Move the surface to new coordinates. 74 | 75 | Coordinates are global, for example 50,50 for a 1920,0+1920x1080 output 76 | is 1970,50 in global coordinates space. 77 | 78 | Use org_kde_plasma_surface.set_output to assign an output 79 | to this surface. 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | Assign a role to a shell surface. 101 | 102 | The compositor handles surfaces depending on their role. 103 | See the explanation below. 104 | 105 | This request fails if the surface already has a role, this means 106 | the surface role may be assigned only once. 107 | 108 | == Surfaces with splash role == 109 | 110 | Splash surfaces are placed above every other surface during the 111 | shell startup phase. 112 | 113 | The surfaces are placed according to the output coordinates. 114 | No size is imposed to those surfaces, the shell has to resize 115 | them according to output size. 116 | 117 | These surfaces are meant to hide the desktop during the startup 118 | phase so that the user will always see a ready to work desktop. 119 | 120 | A shell might not create splash surfaces if the compositor reveals 121 | the desktop in an alternative fashion, for example with a fade 122 | in effect. 123 | 124 | That depends on how much time the desktop usually need to prepare 125 | the workspace or specific design decisions. 126 | This specification doesn't impose any particular design. 127 | 128 | When the startup phase is finished, the shell will send the 129 | org_kde_plasma.desktop_ready request to the compositor. 130 | 131 | == Surfaces with desktop role == 132 | 133 | Desktop surfaces are placed below all other surfaces and are used 134 | to show the actual desktop view with icons, search results or 135 | controls the user will interact with. What to show depends on the 136 | shell implementation. 137 | 138 | The surfaces are placed according to the output coordinates. 139 | No size is imposed to those surfaces, the shell has to resize 140 | them according to output size. 141 | 142 | Only one surface per output can have the desktop role. 143 | 144 | == Surfaces with dashboard role == 145 | 146 | Dashboard surfaces are placed above desktop surfaces and are used to 147 | show additional widgets and controls. 148 | 149 | The surfaces are placed according to the output coordinates. 150 | No size is imposed to those surfaces, the shell has to resize 151 | them according to output size. 152 | 153 | Only one surface per output can have the dashboard role. 154 | 155 | == Surfaces with config role == 156 | 157 | A configuration surface is shown when the user wants to configure 158 | panel or desktop views. 159 | 160 | Only one surface per output can have the config role. 161 | 162 | TODO: This should grab the input like popup menus, right? 163 | 164 | == Surfaces with overlay role == 165 | 166 | Overlays are special surfaces that shows for a limited amount 167 | of time. Such surfaces are useful to display things like volume, 168 | brightness and status changes. 169 | 170 | Compositors may decide to show those surfaces in a layer above 171 | all surfaces, even full screen ones if so is desired. 172 | 173 | == Surfaces with notification role == 174 | 175 | Notification surfaces display informative content for a limited 176 | amount of time. The compositor may decide to show them in a corner 177 | depending on the configuration. 178 | 179 | These surfaces are shown in a layer above all other surfaces except 180 | for full screen ones. 181 | 182 | == Surfaces with lock role == 183 | 184 | The lock surface is shown by the compositor when the session is 185 | locked, users interact with it to unlock the session. 186 | 187 | Compositors should move lock surfaces to 0,0 in output 188 | coordinates space and hide all other surfaces for security sake. 189 | For the same reason it is recommended that clients make the 190 | lock surface as big as the screen. 191 | 192 | Only one surface per output can have the lock role. 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | The panel is on top of other surfaces, windows cannot cover (full screen 205 | windows excluded). 206 | 207 | 208 | 209 | 210 | The panel is hidden automatically and restored when the mouse is over. 211 | 212 | 213 | 214 | 215 | Windows can cover the panel. 216 | 217 | 218 | 219 | 220 | Maximized windows take the whole screen space but the panel is above 221 | the windows. 222 | 223 | 224 | 225 | 226 | 227 | 228 | Set flags bitmask as described by the flag enum. 229 | Pass 0 to unset any flag, the surface will adjust its behavior to 230 | the default. 231 | 232 | Deprecated in Plasma 6. Setting this flag will have no effect. Applications should use layer shell where appropriate. 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | Setting this bit to the window, will make it say it prefers to not be listed in the taskbar. Taskbar implementations may or may not follow this hint. 241 | 242 | 243 | 244 | 245 | 246 | 248 | 249 | 250 | 251 | 252 | A panel surface with panel_behavior auto_hide can perform this request to hide the panel 253 | on a screen edge without unmapping it. The compositor informs the client about the panel 254 | being hidden with the event auto_hidden_panel_hidden. 255 | 256 | The compositor will restore the visibility state of the 257 | surface when the pointer touches the screen edge the panel borders. Once the compositor restores 258 | the visibility the event auto_hidden_panel_shown will be sent. This event will also be sent 259 | if the compositor is unable to hide the panel. 260 | 261 | The client can also request to show the panel again with the request panel_auto_hide_show. 262 | 263 | 264 | 265 | 266 | 267 | A panel surface with panel_behavior auto_hide can perform this request to show the panel 268 | again which got hidden with panel_auto_hide_hide. 269 | 270 | 271 | 272 | 273 | 274 | By default various org_kde_plasma_surface roles do not take focus and cannot be 275 | activated. With this request the compositor can be instructed to pass focus also to this 276 | org_kde_plasma_surface. 277 | 278 | 279 | 280 | 281 | 282 | 283 | An auto-hiding panel got hidden by the compositor. 284 | 285 | 286 | 287 | 288 | 289 | An auto-hiding panel got shown by the compositor. 290 | 291 | 292 | 293 | 294 | 295 | 296 | Setting this bit will indicate that the window prefers not to be listed in a switcher. 297 | 298 | 299 | 300 | 301 | 302 | 303 | Request the initial position of this surface to be under the current 304 | cursor position. Has to be called before attaching any buffer to this surface. 305 | 306 | 307 | 308 | 309 | -------------------------------------------------------------------------------- /src/protocols/plasma-window-management.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 8 | 9 | 10 | 11 | This interface manages application windows. 12 | It provides requests to show and hide the desktop and emits 13 | an event every time a window is created so that the client can 14 | use it to manage the window. 15 | 16 | Only one client can bind this interface at a time. 17 | 18 | Warning! The protocol described in this file is a desktop environment 19 | implementation detail. Regular clients must not use this protocol. 20 | Backward incompatible changes may be added without bumping the major 21 | version of the extension. 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | Tell the compositor to show/hide the desktop. 56 | 57 | 58 | 59 | 60 | 61 | Deprecated: use get_window_by_uuid 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | This event will be sent whenever the show desktop mode changes. E.g. when it is entered 74 | or left. 75 | 76 | On binding the interface the current state is sent. 77 | 78 | 79 | 80 | 81 | 82 | 83 | This event will be sent immediately after a window is mapped. 84 | 85 | 86 | 87 | 88 | 89 | 90 | This event will be sent when stacking order changed and on bind. 91 | 92 | With version 17 this event is deprecated and will no longer be sent. 93 | 94 | 95 | 96 | 97 | 98 | 99 | This event will be sent when stacking order changed and on bind. 100 | 101 | With version 17 this event is deprecated and will no longer be sent. 102 | 103 | 104 | 105 | 106 | 107 | 108 | This event will be sent immediately after a window is mapped. 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | This event will be sent when stacking order changed. 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | Manages and control an application window. 129 | 130 | Only one client can bind this interface at a time. 131 | 132 | 133 | 134 | 135 | Set window state. 136 | 137 | Values for state argument are described by org_kde_plasma_window_management.state 138 | and can be used together in a bitfield. The flags bitfield describes which flags are 139 | supposed to be set, the state bitfield the value for the set flags 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | Deprecated: use enter_virtual_desktop 148 | Maps the window to a different virtual desktop. 149 | 150 | To show the window on all virtual desktops, call the 151 | org_kde_plasma_window.set_state request and specify a on_all_desktops 152 | state in the bitfield. 153 | 154 | 155 | 156 | 157 | 158 | 159 | Sets the geometry of the taskbar entry for this window. 160 | The geometry is relative to a panel in particular. 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | Remove the task geometry information for a particular panel. 172 | 173 | 174 | 175 | 176 | 183 | 184 | 185 | 186 | Close this window. 187 | 188 | 189 | 190 | 191 | 192 | Request an interactive move for this window. 193 | 194 | 195 | 196 | 197 | 198 | Request an interactive resize for this window. 199 | 200 | 201 | 202 | 203 | 204 | Removes the resource bound for this org_kde_plasma_window. 205 | 206 | 207 | 208 | 209 | 210 | The compositor will write the window icon into the provided file descriptor. 211 | The data is a serialized QIcon with QDataStream. 212 | 213 | 214 | 215 | 216 | 217 | 218 | This event will be sent as soon as the window title is changed. 219 | 220 | 221 | 222 | 223 | 224 | 225 | This event will be sent as soon as the application 226 | identifier is changed. 227 | 228 | 229 | 230 | 231 | 232 | 233 | This event will be sent as soon as the window state changes. 234 | 235 | Values for state argument are described by org_kde_plasma_window_management.state. 236 | 237 | 238 | 239 | 240 | 241 | 242 | DEPRECATED: use virtual_desktop_entered and virtual_desktop_left instead 243 | This event will be sent when a window is moved to another 244 | virtual desktop. 245 | 246 | It is not sent if it becomes visible on all virtual desktops though. 247 | 248 | 249 | 250 | 251 | 252 | 253 | This event will be sent whenever the themed icon name changes. May be null. 254 | 255 | 256 | 257 | 258 | 259 | 260 | This event will be sent immediately after the window is closed 261 | and its surface is unmapped. 262 | 263 | 264 | 265 | 266 | 267 | This event will be sent immediately after all initial state been sent to the client. 268 | If the Plasma window is already unmapped, the unmapped event will be sent before the 269 | initial_state event. 270 | 271 | 272 | 273 | 274 | 275 | This event will be sent whenever the parent window of this org_kde_plasma_window changes. 276 | The passed parent is another org_kde_plasma_window and this org_kde_plasma_window is a 277 | transient window to the parent window. If the parent argument is null, this 278 | org_kde_plasma_window does not have a parent window. 279 | 280 | 281 | 282 | 283 | 284 | 285 | This event will be sent whenever the window geometry of this org_kde_plasma_window changes. 286 | The coordinates are in absolute coordinates of the windowing system. 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | This event will be sent whenever the icon of the window changes, but there is no themed 297 | icon name. Common examples are Xwayland windows which have a pixmap based icon. 298 | 299 | The client can request the icon using get_icon. 300 | 301 | 302 | 303 | 304 | 305 | This event will be sent when the compositor has set the process id this window belongs to. 306 | This should be set once before the initial_state is sent. 307 | 308 | 309 | 310 | 311 | 312 | 313 | 314 | 315 | 316 | Make the window enter a virtual desktop. A window can enter more 317 | than one virtual desktop. if the id is empty or invalid, no action will be performed. 318 | 319 | 320 | 321 | 322 | 323 | RFC: do this with an empty id to request_enter_virtual_desktop? 324 | Make the window enter a new virtual desktop. If the server consents the request, 325 | it will create a new virtual desktop and assign the window to it. 326 | 327 | 328 | 329 | 330 | 331 | Make the window exit a virtual desktop. If it exits all desktops it will be considered on all of them. 332 | 333 | 334 | 335 | 336 | 337 | 338 | This event will be sent when the window has entered a new virtual desktop. The window can be on more than one desktop, or none: then is considered on all of them. 339 | 340 | 341 | 342 | 343 | 344 | 345 | This event will be sent when the window left a virtual desktop. If the window leaves all desktops, it can be considered on all. 346 | If the window gets manually added on all desktops, the server has to send virtual_desktop_left for every previous desktop it was in for the window to be really considered on all desktops. 347 | 348 | 349 | 350 | 351 | 352 | 353 | 354 | 355 | This event will be sent after the application menu 356 | for the window has changed. 357 | 358 | 359 | 360 | 361 | 362 | 363 | 364 | Make the window enter an activity. A window can enter more activity. If the id is empty or invalid, no action will be performed. 365 | 366 | 367 | 368 | 369 | 370 | 371 | Make the window exit a an activity. If it exits all activities it will be considered on all of them. 372 | 373 | 374 | 375 | 376 | 377 | 378 | This event will be sent when the window has entered an activity. The window can be on more than one activity, or none: then is considered on all of them. 379 | 380 | 381 | 382 | 383 | 384 | 385 | This event will be sent when the window left an activity. If the window leaves all activities, it will be considered on all. 386 | If the window gets manually added on all activities, the server has to send activity_left for every previous activity it was in for the window to be really considered on all activities. 387 | 388 | 389 | 390 | 391 | 392 | 393 | Requests this window to be displayed in a specific output. 394 | 395 | 396 | 397 | 398 | 399 | 400 | This event will be sent when the X11 resource name of the window has changed. 401 | This is only set for XWayland windows. 402 | 403 | 404 | 405 | 406 | 407 | 408 | This event will be sent whenever the window geometry of this org_kde_plasma_window changes. 409 | The coordinates are in absolute coordinates of the windowing system. 410 | 411 | 412 | 413 | 414 | 415 | 416 | 417 | 418 | 419 | 420 | The activation manager interface provides a way to get notified 421 | when an application is about to be activated. 422 | 423 | 424 | 425 | 426 | Destroy the activation manager object. The activation objects introduced 427 | by this manager object will be unaffected. 428 | 429 | 430 | 431 | 432 | 433 | Will be issued when an app is set to be activated. It offers 434 | an instance of org_kde_plasma_activation that will tell us the app_id 435 | and the extent of the activation. 436 | 437 | 438 | 439 | 440 | 441 | 442 | 443 | 444 | Notify the compositor that the org_kde_plasma_activation object will no 445 | longer be used. 446 | 447 | 448 | 449 | 450 | 451 | 452 | 453 | 454 | 455 | 456 | 457 | 458 | 459 | 460 | 461 | When this object is created, the compositor sends a window event for 462 | each window in the stacking order, and afterwards sends the done event 463 | and destroys this object. 464 | 465 | 466 | 467 | 468 | 469 | 470 | 471 | 472 | 473 | 474 | 475 | 476 | -------------------------------------------------------------------------------- /src/protocols/remote-access.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | -------------------------------------------------------------------------------- /src/protocols/server-decoration-palette.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 8 | 9 | 10 | This interface allows a client to alter the palette of a server side decoration. 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | This interface allows a client to alter the palette of a server side decoration. 20 | 21 | 22 | 23 | Color scheme that should be applied to the window decoration. 24 | Absolute file path, or name of palette in the user's config directory. 25 | The server may choose not to follow the requested style. 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | -------------------------------------------------------------------------------- /src/protocols/server-decoration.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 8 | 9 | 10 | This interface allows to coordinate whether the server should create 11 | a server-side window decoration around a wl_surface representing a 12 | shell surface (wl_shell_surface or similar). By announcing support 13 | for this interface the server indicates that it supports server 14 | side decorations. 15 | 16 | Use in conjunction with zxdg_decoration_manager_v1 is undefined. 17 | 18 | 19 | 20 | When a client creates a server-side decoration object it indicates 21 | that it supports the protocol. The client is supposed to tell the 22 | server whether it wants server-side decorations or will provide 23 | client-side decorations. 24 | 25 | If the client does not create a server-side decoration object for 26 | a surface the server interprets this as lack of support for this 27 | protocol and considers it as client-side decorated. Nevertheless a 28 | client-side decorated surface should use this protocol to indicate 29 | to the server that it does not want a server-side deco. 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | This event is emitted directly after binding the interface. It contains 43 | the default mode for the decoration. When a new server decoration object 44 | is created this new object will be in the default mode until the first 45 | request_mode is requested. 46 | 47 | The server may change the default mode at any time. 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | This event is emitted directly after the decoration is created and 69 | represents the base decoration policy by the server. E.g. a server 70 | which wants all surfaces to be client-side decorated will send Client, 71 | a server which wants server-side decoration will send Server. 72 | 73 | The client can request a different mode through the decoration request. 74 | The server will acknowledge this by another event with the same mode. So 75 | even if a server prefers server-side decoration it's possible to force a 76 | client-side decoration. 77 | 78 | The server may emit this event at any time. In this case the client can 79 | again request a different mode. It's the responsibility of the server to 80 | prevent a feedback loop. 81 | 82 | 83 | 84 | 85 | 86 | -------------------------------------------------------------------------------- /src/protocols/shadow.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | Destroy the org_kde_kwin_shadow_manager object. 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | Destroy the org_kde_kwin_shadow object. If the org_kde_kwin_shadow is 64 | still set on a wl_surface the shadow will be immediately removed. 65 | Prefer to first call the request unset on the org_kde_kwin_shadow_manager and 66 | commit the wl_surface to apply the change. 67 | 68 | 69 | 70 | 71 | -------------------------------------------------------------------------------- /src/protocols/slide.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | Ask the compositor to move the surface from a location to another 21 | with a slide animation. 22 | 23 | The from argument provides a clue about where the slide animation 24 | begins, offset is the distance from screen edge to begin the animation. 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | -------------------------------------------------------------------------------- /src/protocols/surface-extension.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | This file is part of the plugins of the Qt Toolkit. 5 | SPDX-FileCopyrightText: 2012 Digia Plc and/or its subsidiary(-ies). 6 | Contact: http://www.qt-project.org/legal 7 | 8 | SPDX-License-Identifier: BSD-3-Clause 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | -------------------------------------------------------------------------------- /src/protocols/text-input-unstable-v2.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | SPDX-FileCopyrightText: 2012, 2013 Intel Corporation 6 | SPDX-FileCopyrightText: 2015, 2016 Jan Arne Petersen 7 | 8 | SPDX-License-Identifier: MIT-CMU 9 | 10 | 11 | 12 | 13 | The zwp_text_input_v2 interface represents text input and input methods 14 | associated with a seat. It provides enter/leave events to follow the 15 | text input focus for a seat. 16 | 17 | Requests are used to enable/disable the text-input object and set 18 | state information like surrounding and selected text or the content type. 19 | The information about the entered text is sent to the text-input object 20 | via the pre-edit and commit events. Using this interface removes the need 21 | for applications to directly process hardware key events and compose text 22 | out of them. 23 | 24 | Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices 25 | have to always point to the first byte of an UTF-8 encoded code point. 26 | Lengths are not allowed to contain just a part of an UTF-8 encoded code 27 | point. 28 | 29 | State is sent by the state requests (set_surrounding_text, 30 | set_content_type, set_cursor_rectangle and set_preferred_language) and 31 | an update_state request. After an enter or an input_method_change event 32 | all state information is invalidated and needs to be resent from the 33 | client. A reset or entering a new widget on client side also 34 | invalidates all current state information. 35 | 36 | 37 | 38 | 39 | Destroy the wp_text_input object. Also disables all surfaces enabled 40 | through this wp_text_input object 41 | 42 | 43 | 44 | 45 | 46 | Enable text input in a surface (usually when a text entry inside of it 47 | has focus). 48 | 49 | This can be called before or after a surface gets text (or keyboard) 50 | focus via the enter event. Text input to a surface is only active 51 | when it has the current text (or keyboard) focus and is enabled. 52 | 53 | 54 | 55 | 56 | 57 | 58 | Disable text input in a surface (typically when there is no focus on any 59 | text entry inside the surface). 60 | 61 | 62 | 63 | 64 | 65 | 66 | Requests input panels (virtual keyboard) to show. 67 | 68 | This should be used for example to show a virtual keyboard again 69 | (with a tap) after it was closed by pressing on a close button on the 70 | keyboard. 71 | 72 | 73 | 74 | 75 | 76 | Requests input panels (virtual keyboard) to hide. 77 | 78 | 79 | 80 | 81 | 82 | Sets the plain surrounding text around the input position. Text is 83 | UTF-8 encoded. Cursor is the byte offset within the surrounding text. 84 | Anchor is the byte offset of the selection anchor within the 85 | surrounding text. If there is no selected text, anchor is the same as 86 | cursor. 87 | 88 | Make sure to always send some text before and after the cursor 89 | except when the cursor is at the beginning or end of text. 90 | 91 | When there was a configure_surrounding_text event take the 92 | before_cursor and after_cursor arguments into account for picking how 93 | much surrounding text to send. 94 | 95 | There is a maximum length of wayland messages so text can not be 96 | longer than 4000 bytes. 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | Content hint is a bitmask to allow to modify the behavior of the text 106 | input. 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | The content purpose allows to specify the primary purpose of a text 124 | input. 125 | 126 | This allows an input method to show special purpose input panels with 127 | extra characters or to disallow some characters. 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | Sets the content purpose and content hint. While the purpose is the 147 | basic purpose of an input field, the hint flags allow to modify some 148 | of the behavior. 149 | 150 | When no content type is explicitly set, a normal content purpose with 151 | none hint should be assumed. 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | Sets the cursor outline as a x, y, width, height rectangle in surface 160 | local coordinates. 161 | 162 | Allows the compositor to put a window with word suggestions near the 163 | cursor. 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | Sets a specific language. This allows for example a virtual keyboard to 174 | show a language specific layout. The "language" argument is a RFC-3066 175 | format language tag. 176 | 177 | It could be used for example in a word processor to indicate language of 178 | currently edited document or in an instant message application which 179 | tracks languages of contacts. 180 | 181 | 182 | 183 | 184 | 185 | 186 | Defines the reason for sending an updated state. 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | Allows to atomically send state updates from client. 197 | 198 | This request should follow after a batch of state updating requests 199 | like set_surrounding_text, set_content_type, set_cursor_rectangle and 200 | set_preferred_language. 201 | 202 | The flags field indicates why an updated state is sent to the input 203 | method. 204 | 205 | Reset should be used by an editor widget after the text was changed 206 | outside of the normal input method flow. 207 | 208 | For "change" it is enough to send the changed state, else the full 209 | state should be send. 210 | 211 | Serial should be set to the serial from the last enter or 212 | input_method_changed event. 213 | 214 | To make sure to not receive outdated input method events after a 215 | reset or switching to a new widget wl_display_sync() should be used 216 | after update_state in these cases. 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | Notification that this seat's text-input focus is on a certain surface. 225 | 226 | When the seat has the keyboard capability the text-input focus follows 227 | the keyboard focus. 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | Notification that this seat's text-input focus is no longer on 236 | a certain surface. 237 | 238 | The leave notification is sent before the enter notification 239 | for the new focus. 240 | 241 | When the seat has the keyboard capability the text-input focus follows 242 | the keyboard focus. 243 | 244 | 245 | 246 | 247 | 248 | 249 | 251 | 253 | 254 | 255 | 256 | 257 | Notification that the visibility of the input panel (virtual keyboard) 258 | changed. 259 | 260 | The rectangle x, y, width, height defines the area overlapped by the 261 | input panel (virtual keyboard) on the surface having the text 262 | focus in surface local coordinates. 263 | 264 | That can be used to make sure widgets are visible and not covered by 265 | a virtual keyboard. 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | Notify when a new composing text (pre-edit) should be set around the 277 | current cursor position. Any previously set composing text should 278 | be removed. 279 | 280 | The commit text can be used to replace the composing text in some cases 281 | (for example when losing focus). 282 | 283 | The text input should also handle all preedit_style and preedit_cursor 284 | events occurring directly before preedit_string. 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | 298 | 299 | 300 | 301 | 302 | 303 | Sets styling information on composing text. The style is applied for 304 | length bytes from index relative to the beginning of the composing 305 | text (as byte offset). Multiple styles can be applied to a composing 306 | text by sending multiple preedit_styling events. 307 | 308 | This event is handled as part of a following preedit_string event. 309 | 310 | 311 | 312 | 313 | 314 | 315 | 316 | 317 | Sets the cursor position inside the composing text (as byte 318 | offset) relative to the start of the composing text. When index is a 319 | negative number no cursor is shown. 320 | 321 | When no preedit_cursor event is sent the cursor will be at the end of 322 | the composing text by default. 323 | 324 | This event is handled as part of a following preedit_string event. 325 | 326 | 327 | 328 | 329 | 330 | 331 | Notify when text should be inserted into the editor widget. The text to 332 | commit could be either just a single character after a key press or the 333 | result of some composing (pre-edit). It could be also an empty text 334 | when some text should be removed (see delete_surrounding_text) or when 335 | the input cursor should be moved (see cursor_position). 336 | 337 | Any previously set composing text should be removed. 338 | 339 | 340 | 341 | 342 | 343 | 344 | Notify when the cursor or anchor position should be modified. 345 | 346 | This event should be handled as part of a following commit_string 347 | event. 348 | 349 | The text between anchor and index should be selected. 350 | 351 | 352 | 353 | 354 | 355 | 356 | 357 | Notify when the text around the current cursor position should be 358 | deleted. BeforeLength and afterLength is the length (in bytes) of text 359 | before and after the current cursor position (excluding the selection) 360 | to delete. 361 | 362 | This event should be handled as part of a following commit_string 363 | or preedit_string event. 364 | 365 | 366 | 367 | 368 | 369 | 370 | 371 | Transfer an array of 0-terminated modifiers names. The position in 372 | the array is the index of the modifier as used in the modifiers 373 | bitmask in the keysym event. 374 | 375 | 376 | 377 | 378 | 379 | 380 | Notify when a key event was sent. Key events should not be used 381 | for normal text input operations, which should be done with 382 | commit_string, delete_surrounding_text, etc. The key event follows 383 | the wl_keyboard key event convention. Sym is a XKB keysym, state a 384 | wl_keyboard key_state. Modifiers are a mask for effective modifiers 385 | (where the modifier indices are set by the modifiers_map event) 386 | 387 | 388 | 389 | 390 | 391 | 392 | 393 | 394 | 395 | Sets the language of the input text. The "language" argument is a RFC-3066 396 | format language tag. 397 | 398 | 399 | 400 | 401 | 402 | 403 | 404 | 405 | 406 | 407 | 408 | 409 | Sets the text direction of input text. 410 | 411 | It is mainly needed for showing input cursor on correct side of the 412 | editor when there is no input yet done and making sure neutral 413 | direction text is laid out properly. 414 | 415 | 416 | 417 | 418 | 419 | 420 | Configure what amount of surrounding text is expected by the 421 | input method. The surrounding text will be sent in the 422 | set_surrounding_text request on the following state information updates. 423 | 424 | 425 | 426 | 427 | 428 | 429 | 430 | The input method changed on compositor side, which invalidates all 431 | current state information. New state information should be sent from 432 | the client via state requests (set_surrounding_text, 433 | set_content_hint, ...) and update_state. 434 | 435 | 436 | 437 | 438 | 439 | 440 | 441 | 442 | A factory for text-input objects. This object is a global singleton. 443 | 444 | 445 | 446 | 447 | Destroy the wp_text_input_manager object. 448 | 449 | 450 | 451 | 452 | 453 | Creates a new text-input object for a given seat. 454 | 455 | 456 | 457 | 458 | 459 | 460 | -------------------------------------------------------------------------------- /src/protocols/text-input.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | SPDX-FileCopyrightText: 2012, 2013 Intel Corporation 6 | 7 | SPDX-License-Identifier: MIT-CMU 8 | 9 | 10 | 11 | 12 | An object used for text input. Adds support for text input and input 13 | methods to applications. A text-input object is created from a 14 | wl_text_input_manager and corresponds typically to a text entry in an 15 | application. 16 | Requests are used to activate/deactivate the text-input object and set 17 | state information like surrounding and selected text or the content type. 18 | The information about entered text is sent to the text-input object via 19 | the pre-edit and commit events. Using this interface removes the need 20 | for applications to directly process hardware key events and compose text 21 | out of them. 22 | 23 | Text is generally UTF-8 encoded, indices and lengths are in bytes. 24 | 25 | Serials are used to synchronize the state between the text input and 26 | an input method. New serials are sent by the text input in the 27 | commit_state request and are used by the input method to indicate 28 | the known text input state in events like preedit_string, commit_string, 29 | and keysym. The text input can then ignore events from the input method 30 | which are based on an outdated state (for example after a reset). 31 | 32 | 33 | 34 | Requests the text-input object to be activated (typically when the 35 | text entry gets focus). 36 | The seat argument is a wl_seat which maintains the focus for this 37 | activation. The surface argument is a wl_surface assigned to the 38 | text-input object and tracked for focus lost. The enter event 39 | is emitted on successful activation. 40 | 41 | 42 | 43 | 44 | 45 | 46 | Requests the text-input object to be deactivated (typically when the 47 | text entry lost focus). The seat argument is a wl_seat which was used 48 | for activation. 49 | 50 | 51 | 52 | 53 | 54 | Requests input panels (virtual keyboard) to show. 55 | 56 | 57 | 58 | 59 | Requests input panels (virtual keyboard) to hide. 60 | 61 | 62 | 63 | 64 | Should be called by an editor widget when the input state should be 65 | reset, for example after the text was changed outside of the normal 66 | input method flow. 67 | 68 | 69 | 70 | 71 | Sets the plain surrounding text around the input position. Text is 72 | UTF-8 encoded. Cursor is the byte offset within the 73 | surrounding text. Anchor is the byte offset of the 74 | selection anchor within the surrounding text. If there is no selected 75 | text anchor is the same as cursor. 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | Content hint is a bitmask to allow to modify the behavior of the text 84 | input. 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | The content purpose allows to specify the primary purpose of a text 103 | input. 104 | 105 | This allows an input method to show special purpose input panels with 106 | extra characters or to disallow some characters. 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | Sets the content purpose and content hint. While the purpose is the 125 | basic purpose of an input field, the hint flags allow to modify some 126 | of the behavior. 127 | 128 | When no content type is explicitly set, a normal content purpose with 129 | default hints (auto completion, auto correction, auto capitalization) 130 | should be assumed. 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | Sets a specific language. This allows for example a virtual keyboard to 144 | show a language specific layout. The "language" argument is a RFC-3066 145 | format language tag. 146 | 147 | It could be used for example in a word processor to indicate language of 148 | currently edited document or in an instant message application which tracks 149 | languages of contacts. 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | Notify the text-input object when it received focus. Typically in 163 | response to an activate request. 164 | 165 | 166 | 167 | 168 | 169 | Notify the text-input object when it lost focus. Either in response 170 | to a deactivate request or when the assigned surface lost focus or was 171 | destroyed. 172 | 173 | 174 | 175 | 176 | Transfer an array of 0-terminated modifiers names. The position in 177 | the array is the index of the modifier as used in the modifiers 178 | bitmask in the keysym event. 179 | 180 | 181 | 182 | 183 | 184 | Notify when the visibility state of the input panel changed. 185 | 186 | 187 | 188 | 189 | 190 | Notify when a new composing text (pre-edit) should be set around the 191 | current cursor position. Any previously set composing text should 192 | be removed. 193 | 194 | The commit text can be used to replace the preedit text on reset 195 | (for example on unfocus). 196 | 197 | The text input should also handle all preedit_style and preedit_cursor 198 | events occurring directly before preedit_string. 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | Sets styling information on composing text. The style is applied for 217 | length bytes from index relative to the beginning of the composing 218 | text (as byte offset). Multiple styles can 219 | be applied to a composing text by sending multiple preedit_styling 220 | events. 221 | 222 | This event is handled as part of a following preedit_string event. 223 | 224 | 225 | 226 | 227 | 228 | 229 | 230 | Sets the cursor position inside the composing text (as byte 231 | offset) relative to the start of the composing text. When index is a 232 | negative number no cursor is shown. 233 | 234 | This event is handled as part of a following preedit_string event. 235 | 236 | 237 | 238 | 239 | 240 | Notify when text should be inserted into the editor widget. The text to 241 | commit could be either just a single character after a key press or the 242 | result of some composing (pre-edit). It could be also an empty text 243 | when some text should be removed (see delete_surrounding_text) or when 244 | the input cursor should be moved (see cursor_position). 245 | 246 | Any previously set composing text should be removed. 247 | 248 | 249 | 250 | 251 | 252 | 253 | Notify when the cursor or anchor position should be modified. 254 | 255 | This event should be handled as part of a following commit_string 256 | event. 257 | 258 | 259 | 260 | 261 | 262 | 263 | Notify when the text around the current cursor position should be 264 | deleted. 265 | 266 | Index is relative to the current cursor (in bytes). 267 | Length is the length of deleted text (in bytes). 268 | 269 | This event should be handled as part of a following commit_string 270 | event. 271 | 272 | 273 | 274 | 275 | 276 | 277 | Notify when a key event was sent. Key events should not be used 278 | for normal text input operations, which should be done with 279 | commit_string, delete_surrounding_text, etc. The key event follows 280 | the wl_keyboard key event convention. Sym is a XKB keysym, state a 281 | wl_keyboard key_state. Modifiers are a mask for effective modifiers 282 | (where the modifier indices are set by the modifiers_map event) 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | Sets the language of the input text. The "language" argument is a RFC-3066 293 | format language tag. 294 | 295 | 296 | 297 | 298 | 299 | 300 | 301 | 302 | 303 | 304 | 305 | Sets the text direction of input text. 306 | 307 | It is mainly needed for showing input cursor on correct side of the 308 | editor when there is no input yet done and making sure neutral 309 | direction text is laid out properly. 310 | 311 | 312 | 313 | 314 | 315 | 316 | 317 | 318 | A factory for text-input objects. This object is a global singleton. 319 | 320 | 321 | 322 | Creates a new text-input object. 323 | 324 | 325 | 326 | 327 | 328 | -------------------------------------------------------------------------------- /src/protocols/wayland-eglstream-controller.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | SPDX-FileCopyrightText: 2017-2018, NVIDIA CORPORATION. All rights reserved. 5 | 6 | SPDX-License-Identifier: MIT 7 | 8 | 9 | 11 | 12 | 13 | - dont_care: Using this enum will tell the server to make its own 14 | decisions regarding present mode. 15 | 16 | - fifo: Tells the server to use a fifo present mode. The decision to 17 | use fifo synchronous is left up to the server. 18 | 19 | - mailbox: Tells the server to use a mailbox present mode. 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | - present_mode: Must be one of wl_eglstream_controller_present_mode. Tells the 29 | server the desired present mode that should be used. 30 | 31 | - fifo_length: Only valid when the present_mode attrib is provided and its 32 | value is specified as fifo. Tells the server the desired fifo 33 | length to be used when the desired present_mode is fifo. 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | Creates the corresponding server side EGLStream from the given wl_buffer 42 | and attaches a consumer to it. 43 | 44 | 47 | 49 | 50 | 51 | 52 | 53 | Creates the corresponding server side EGLStream from the given wl_buffer 54 | and attaches a consumer to it using the given attributes. 55 | 56 | 59 | 61 | 63 | 64 | It contains key-value pairs compatible with intptr_t type. A key must 65 | be one of wl_eglstream_controller_attrib enumeration values. What a value 66 | represents is attribute-specific. 67 | 68 | 69 | 70 | 71 | 72 | -------------------------------------------------------------------------------- /src/protocols/zkde-screencast-unstable-v1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 6 | SPDX-License-Identifier: LGPL-2.1-or-later 7 | ]]> 8 | 9 | 10 | Warning! The protocol described in this file is a desktop environment 11 | implementation detail. Regular clients must not use this protocol. 12 | Backward incompatible changes may be added without bumping the major 13 | version of the extension. 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | Destroy the zkde_screencast_unstable_v1 object. 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | Since version 5, the compositor will choose the highest scale 55 | factor for the region if the given scale is 0.0. 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | --------------------------------------------------------------------------------