Changes - SailfishOS Open Build Service

Changes of Revision 3

We truncated the diff of some files because they were too big. If you want to see the full diff for every file, click here.

[-] [+]	Changed	_service:tar_git:wayland-protocols.changes
@@ -1,6 +1,5 @@ -* Tue Jan 03 2023 Matti Lehtimäki <matti.lehtimaki@jolla.com> - 1.31.0+git1 +* Fri Mar 11 2022 Adam Pigg <adam@piggz.co.uk> - 1.24.0+git1 - [git] Move submodule repos to github. JB#51085 -- [wayland-protocols] Update to version 1.31. JB#59703 * Mon May 31 2021 Matti Lehtimäki <matti.lehtimaki@jolla.com> - 1.21.0+git1 - [wayland-protocols] Update to version 1.21. JB#54463
[-] [+]	Changed	_service:tar_git:wayland-protocols.spec ^
@@ -1,7 +1,7 @@ Name: wayland-protocols Summary: Wayland protocols that adds functionality not available in the core protocol -Version: 1.31.0+git1 +Version: 1.24.0+git1 Release: 1 License: MIT URL: http://wayland.freedesktop.org/
[-] [+]	Changed	_service ^
@@ -1,6 +1,6 @@ <services> <service name="tar_git"> - <param name="url">https://github.com/sailfishos/wayland-protocols</param> + <param name="url">https://github.com/sailfish-on-dontbeevil/wayland-protocols</param> <param name="branch">master</param> <param name="revision"></param> <param name="token"/>
[-] [+]	Changed	_service:tar_git:wayland-protocols-1.24.0+git1.tar.xz/wayland-protocols/.gitlab-ci.yml ^
@@ -19,9 +19,8 @@ .debian: variables: FDO_DISTRIBUTION_VERSION: bullseye - FDO_DISTRIBUTION_PACKAGES: 'build-essential pkg-config meson git ca-certificates libffi-dev libexpat1-dev libxml2-dev' - FDO_DISTRIBUTION_TAG: '2022-01-19.0' - FDO_DISTRIBUTION_EXEC: 'env FDO_CI_CONCURRENT=${FDO_CI_CONCURRENT} ./.gitlab-ci/debian-install.sh' + FDO_DISTRIBUTION_PACKAGES: 'build-essential pkg-config libwayland-dev meson' + FDO_DISTRIBUTION_TAG: '2021-11-09.0' check-commit: extends: @@ -53,8 +52,3 @@ - ninja -C build - meson test -C build - ninja -C build install - artifacts: - name: wayland-protocols-$CI_COMMIT_SHA - when: always - paths: - - $CI_PROJECT_DIR/build/meson-logs
[-] [+]	Changed	_service:tar_git:wayland-protocols-1.24.0+git1.tar.xz/wayland-protocols/GOVERNANCE.md ^
@@ -77,7 +77,7 @@ implementations (either 1 client + 2 servers, or 2 clients + 1 server) to be eligible for inclusion. 5. Protocols in the "ext" namespace are eligible for inclusion only if ACKed by - at least 2 members. + at least one other member. 6. Protocols in the "ext" namespace must have at least one open-source client & one open-source server implementation to be eligible for inclusion. 7. "Open-source" is defined as distributed with an Open Source Initiative
[-] [+]	Changed	_service:tar_git:wayland-protocols-1.24.0+git1.tar.xz/wayland-protocols/MEMBERS.md ^
@@ -9,8 +9,7 @@ Alan Griffiths <alan.griffiths@canonical.com> - Qt: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io> (@eskilblomfeldt) -- Smithay/Cosmic: Victoria Brekenfeld <wayland@drakulix.de> (@drakulix), - Weston: Pekka Paalanen <pekka.paalanen@collabora.com> (@pq), Daniel Stone <daniel@fooishbar.org> (@daniels) -- wlroots/Sway: Simon Ser <contact@emersion.fr> (@emersion), - Simon Zeni <simon@bl4ckb0ne.ca> (@bl4ckb0ne) +- wlroots/Sway: Drew DeVault <sir@cmpwn.com> (@ddevault), + Simon Ser <contact@emersion.fr> (@emersion)
[-] [+]	Changed	_service:tar_git:wayland-protocols-1.24.0+git1.tar.xz/wayland-protocols/README.md ^
@@ -141,26 +141,6 @@ only be done by creating a new major version of the extension. ``` -## Use of RFC 2119 keywords - -Descriptions of all new protocols must use (in lowercase) and adhere to the -proper meaning of the keywords described in -[RFC 2119](https://www.rfc-editor.org/info/rfc2119). - -All protocol descriptions that follow the guidelines in RFC 2119 must -incorporate the following text in their toplevel protocol description section: - -``` -The key words "must", "must not", "required", "shall", "shall not", "should", -"should not", "recommended", "may", and "optional" in this document are to -be interpreted as described in IETF RFC 2119. -``` - -Note that not all existing protocol descriptions conform to RFC 2119. Protocol -maintainers are encouraged to audit their descriptions, update them as needed -to follow RFC 2119 guidelines, and mark them as conformant in the way described -in the previous paragraph. - ## Backward compatible protocol changes A protocol may receive backward compatible additions and changes. This
[-] [+]	Changed	_service:tar_git:wayland-protocols-1.24.0+git1.tar.xz/wayland-protocols/meson.build ^
@@ -1,6 +1,6 @@ project('wayland-protocols', - version: '1.31', - meson_version: '>= 0.55.0', + version: '1.24', + meson_version: '>= 0.54.0', license: 'MIT/Expat', ) @@ -36,15 +36,8 @@ } staging_protocols = { - 'content-type': ['v1'], - 'drm-lease': ['v1'], - 'ext-idle-notify': ['v1'], - 'ext-session-lock': ['v1'], - 'fractional-scale': ['v1'], - 'single-pixel-buffer': ['v1'], - 'tearing-control': ['v1'], 'xdg-activation': ['v1'], - 'xwayland-shell': ['v1'], + 'drm-lease': ['v1'], } protocol_files = []
[-] [+]	Changed	_service:tar_git:wayland-protocols-1.24.0+git1.tar.xz/wayland-protocols/stable/presentation-time/presentation-time.xml ^
@@ -198,7 +198,7 @@ </entry> </enum> - <event name="presented" type="destructor"> + <event name="presented"> <description summary="the content update was displayed"> The associated content update was displayed to the user at the indicated time (tv_sec_hi/lo, tv_nsec). For the interpretation of @@ -256,7 +256,7 @@ <arg name="flags" type="uint" enum="kind" summary="combination of 'kind' values"/> </event> - <event name="discarded" type="destructor"> + <event name="discarded"> <description summary="the content update was not displayed"> The content update was never displayed to the user. </description>
[-] [+]	Changed	_service:tar_git:wayland-protocols-1.24.0+git1.tar.xz/wayland-protocols/stable/viewporter/viewporter.xml ^
@@ -111,6 +111,12 @@ when the surface state is applied. A NULL wl_buffer does not raise the out_of_buffer error. + The x, y arguments of wl_surface.attach are applied as normal to + the surface. They indicate how many pixels to remove from the + surface size from the left and the top. In other words, they are + still in the surface-local coordinate system, just like dst_width + and dst_height are. + If the wl_surface associated with the wp_viewport is destroyed, all wp_viewport requests except 'destroy' raise the protocol error no_surface.
[-] [+]	Changed	_service:tar_git:wayland-protocols-1.24.0+git1.tar.xz/wayland-protocols/stable/xdg-shell/xdg-shell.xml ^
@@ -29,7 +29,7 @@ DEALINGS IN THE SOFTWARE. </copyright> - <interface name="xdg_wm_base" version="5"> + <interface name="xdg_wm_base" version="3"> <description summary="create desktop-style surfaces"> The xdg_wm_base interface is exposed as a global object enabling clients to turn their wl_surfaces into windows in a desktop environment. It @@ -50,8 +50,6 @@ summary="the client provided an invalid surface state"/> <entry name="invalid_positioner" value="5" summary="the client provided an invalid positioner"/> - <entry name="unresponsive" value="6" - summary="the client didn’t respond to a ping event in time"/> </enum> <request name="destroy" type="destructor"> @@ -60,7 +58,7 @@ Destroying a bound xdg_wm_base object while there are surfaces still alive created by this xdg_wm_base object instance is illegal - and will result in a defunct_surfaces error. + and will result in a protocol error. </description> </request> @@ -79,7 +77,7 @@ itself is not a role, the corresponding surface may only be assigned a role extending xdg_surface, such as xdg_toplevel or xdg_popup. It is illegal to create an xdg_surface for a wl_surface which already has an - assigned role and this will result in a role error. + assigned role and this will result in a protocol error. This creates an xdg_surface for the given surface. An xdg_surface is used as basis to define a role to a given surface, such as xdg_toplevel @@ -96,8 +94,7 @@ <request name="pong"> <description summary="respond to a ping event"> A client must respond to a ping event with a pong request or - the client may be deemed unresponsive. See xdg_wm_base.ping - and xdg_wm_base.error.unresponsive. + the client may be deemed unresponsive. See xdg_wm_base.ping. </description> <arg name="serial" type="uint" summary="serial of the ping event"/> </request> @@ -111,9 +108,7 @@ Compositors can use this to determine if the client is still alive. It's unspecified what will happen if the client doesn't respond to the ping request, or in what timeframe. Clients should - try to respond in a reasonable amount of time. The “unresponsive” - error is provided for compositors that wish to disconnect unresponsive - clients. + try to respond in a reasonable amount of time. A compositor is free to ping in any way it wants, but a client must always respond to any xdg_wm_base object it created. @@ -122,7 +117,7 @@ </event> </interface> - <interface name="xdg_positioner" version="5"> + <interface name="xdg_positioner" version="3"> <description summary="child surface positioner"> The xdg_positioner provides a collection of rules for the placement of a child surface relative to a parent surface. Rules can be defined to ensure @@ -142,7 +137,7 @@ For an xdg_positioner object to be considered complete, it must have a non-zero size set by set_size, and a non-zero anchor rectangle set by set_anchor_rect. Passing an incomplete xdg_positioner object when - positioning a surface raises an invalid_positioner error. + positioning a surface raises an error. </description> <enum name="error"> @@ -230,8 +225,7 @@ specified (e.g. 'bottom_right' or 'top_left'), then the child surface will be placed towards the specified gravity; otherwise, the child surface will be centered over the anchor point on any axis that had no - gravity specified. If the gravity is not in the ‘gravity’ enum, an - invalid_input error is raised. + gravity specified. </description> <arg name="gravity" type="uint" enum="gravity" summary="gravity direction"/> @@ -407,7 +401,7 @@ </request> </interface> - <interface name="xdg_surface" version="5"> + <interface name="xdg_surface" version="3"> <description summary="desktop user interface surface base interface"> An interface that may be implemented by a wl_surface, for implementations that provide a desktop-style user interface. @@ -452,30 +446,19 @@ A newly-unmapped surface is considered to have met condition (1) out of the 3 required conditions for mapping a surface if its role surface - has not been destroyed, i.e. the client must perform the initial commit - again before attaching a buffer. + has not been destroyed. </description> <enum name="error"> - <entry name="not_constructed" value="1" - summary="Surface was not fully constructed"/> - <entry name="already_constructed" value="2" - summary="Surface was already constructed"/> - <entry name="unconfigured_buffer" value="3" - summary="Attaching a buffer to an unconfigured surface"/> - <entry name="invalid_serial" value="4" - summary="Invalid serial number when acking a configure event"/> - <entry name="invalid_size" value="5" - summary="Width or height was zero or negative"/> - <entry name="defunct_role_object" value="6" - summary="Surface was destroyed before its role object"/> + <entry name="not_constructed" value="1"/> + <entry name="already_constructed" value="2"/> + <entry name="unconfigured_buffer" value="3"/> </enum> <request name="destroy" type="destructor"> <description summary="destroy the xdg_surface"> Destroy the xdg_surface object. An xdg_surface must only be destroyed - after its role object has been destroyed, otherwise - a defunct_role_object error is raised. + after its role object has been destroyed. </description> </request> @@ -533,10 +516,10 @@ the wl_surface associated with this xdg_surface. The width and height must be greater than zero. Setting an invalid size - will raise an invalid_size error. When applied, the effective window - geometry will be the set window geometry clamped to the bounding - rectangle of the combined geometry of the surface of the xdg_surface and - the associated subsurfaces. + will raise an error. When applied, the effective window geometry will be + the set window geometry clamped to the bounding rectangle of the + combined geometry of the surface of the xdg_surface and the associated + subsurfaces. </description> <arg name="x" type="int"/> <arg name="y" type="int"/> @@ -557,8 +540,6 @@ If the client receives multiple configure events before it can respond to one, it only has to ack the last configure event. - Acking a configure event that was never sent raises an invalid_serial - error. A client is not required to commit immediately after sending an ack_configure request - it may even ack_configure several times @@ -567,17 +548,6 @@ A client may send multiple ack_configure requests before committing, but only the last request sent before a commit indicates which configure event the client really is responding to. - - Sending an ack_configure request consumes the serial number sent with - the request, as well as serial numbers sent by all configure events - sent on this xdg_surface prior to the configure event referenced by - the committed serial. - - It is an error to issue multiple ack_configure requests referencing a - serial from the same configure event, or to issue an ack_configure - request referencing a serial from a configure event issued before the - event identified by the last ack_configure request for the same - xdg_surface. Doing so will raise an invalid_serial error. </description> <arg name="serial" type="uint" summary="the serial from the configure event"/> </request> @@ -606,7 +576,7 @@ </interface> - <interface name="xdg_toplevel" version="5"> + <interface name="xdg_toplevel" version="3"> <description summary="toplevel surface"> This interface defines an xdg_surface role which allows a surface to, among other things, set window-like properties such as maximize, @@ -634,37 +604,24 @@ </description> </request> - <enum name="error"> - <entry name="invalid_resize_edge" value="0" summary="provided value is - not a valid variant of the resize_edge enum"/> - <entry name="invalid_parent" value="1" - summary="invalid parent toplevel"/> - <entry name="invalid_size" value="2" - summary="client provided an invalid min or max size"/> - </enum> - <request name="set_parent"> <description summary="set the parent of this surface"> Set the "parent" of this surface. This surface should be stacked above the parent surface and all other ancestor surfaces. - Parent surfaces should be set on dialogs, toolboxes, or other
[-] [+]	Changed	_service:tar_git:wayland-protocols-1.24.0+git1.tar.xz/wayland-protocols/staging/drm-lease/drm-lease-v1.xml ^
@@ -120,7 +120,7 @@ </description> </event> - <event name="released" type="destructor"> + <event name="released"> <description summary="the compositor has finished using the device"> This event is sent in response to the release request and indicates that the compositor is done sending connector events.
[-] [+]	Changed	_service:tar_git:wayland-protocols-1.24.0+git1.tar.xz/wayland-protocols/tests/meson.build ^
@@ -1,6 +1,6 @@ prog_scan_sh = find_program('scan.sh') -dep_scanner = dependency('wayland-scanner', version: '>=1.20.0', native: true) -prog_scanner = find_program(dep_scanner.get_variable(pkgconfig: 'wayland_scanner')) +dep_scanner = dependency('wayland-scanner', native: true) +prog_scanner = find_program(dep_scanner.get_pkgconfig_variable('wayland_scanner')) libwayland = [ dependency('wayland-client'), @@ -14,7 +14,7 @@ test(test_name, prog_scan_sh, args: protocol_path, env: [ - 'SCANNER=@0@'.format(prog_scanner.full_path()), + 'SCANNER=@0@'.format(prog_scanner.path()), ] ) endforeach
[-] [+]	Changed	_service:tar_git:wayland-protocols-1.24.0+git1.tar.xz/wayland-protocols/unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml ^
@@ -217,7 +217,7 @@ </interface> <interface name="zwp_fullscreen_shell_mode_feedback_v1" version="1"> - <event name="mode_successful" type="destructor"> + <event name="mode_successful"> <description summary="mode switch succeeded"> This event indicates that the attempted mode switch operation was successful. A surface of the size requested in the mode switch @@ -228,7 +228,7 @@ </description> </event> - <event name="mode_failed" type="destructor"> + <event name="mode_failed"> <description summary="mode switch failed"> This event indicates that the attempted mode switch operation failed. This may be because the requested output mode is not @@ -239,7 +239,7 @@ </description> </event> - <event name="present_cancelled" type="destructor"> + <event name="present_cancelled"> <description summary="mode switch cancelled"> This event indicates that the attempted mode switch operation was cancelled. Most likely this is because the client requested a
[-] [+]	Changed	_service:tar_git:wayland-protocols-1.24.0+git1.tar.xz/wayland-protocols/unstable/linux-dmabuf/feedback.rst ^
@@ -180,7 +180,7 @@ .. code-block:: c - dev_t dev; + struct dev_t dev; assert(dev_array->size == sizeof(dev)); memcpy(&dev, dev_array->data, sizeof(dev));
[-] [+]	Changed	_service:tar_git:wayland-protocols-1.24.0+git1.tar.xz/wayland-protocols/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml ^
@@ -413,16 +413,16 @@ configuration. In particular, compositors should avoid sending the exact same parameters multiple times in a row. - The tranche_target_device and tranche_formats events are grouped by + The tranche_target_device and tranche_modifier events are grouped by tranches of preference. For each tranche, a tranche_target_device, one - tranche_flags and one or more tranche_formats events are sent, followed + tranche_flags and one or more tranche_modifier events are sent, followed by a tranche_done event finishing the list. The tranches are sent in descending order of preference. All formats and modifiers in the same tranche have the same preference. To send parameters, the compositor sends one main_device event, tranches (each consisting of one tranche_target_device event, one tranche_flags - event, tranche_formats events and then a tranche_done event), then one + event, tranche_modifier events and then a tranche_done event), then one done event. </description> @@ -495,9 +495,9 @@ <event name="tranche_done"> <description summary="a preference tranche has been sent"> - This event splits tranche_target_device and tranche_formats events in + This event splits tranche_target_device and tranche_modifier events in preference tranches. It is sent after a set of tranche_target_device - and tranche_formats events; it represents the end of a tranche. The + and tranche_modifier events; it represents the end of a tranche. The next tranche will have a lower preference. </description> </event>
[-] [+]	Changed	_service:tar_git:wayland-protocols-1.24.0+git1.tar.xz/wayland-protocols/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml ^
@@ -219,7 +219,7 @@ 'immediate_release' event it is automatically destroyed. </description> - <event name="fenced_release" type="destructor"> + <event name="fenced_release"> <description summary="release buffer with fence"> Sent when the compositor has finalised its usage of the associated buffer for the relevant commit, providing a dma_fence which will be @@ -236,7 +236,7 @@ <arg name="fence" type="fd" summary="fence for last operation on buffer"/> </event> - <event name="immediate_release" type="destructor"> + <event name="immediate_release"> <description summary="release buffer immediately"> Sent when the compositor has finalised its usage of the associated buffer for the relevant commit, and either performed no operations
[-] [+]	Changed	_service:tar_git:wayland-protocols-1.24.0+git1.tar.xz/wayland-protocols/unstable/tablet/tablet-unstable-v2.xml ^
@@ -1156,7 +1156,7 @@ </event> <event name="leave"> - <description summary="leave event"> + <description summary="enter event"> Notification that this pad is no longer focused on the specified surface. </description>
[-] [+]	Changed	_service:tar_git:wayland-protocols-1.24.0+git1.tar.xz/wayland-protocols/unstable/text-input/text-input-unstable-v3.xml ^
@@ -422,14 +422,9 @@ The serial number reflects the last state of the zwp_text_input_v3 object known to the compositor. The value of the serial argument must be equal to the number of commit requests already issued on that object. - When the client receives a done event with a serial different than the - number of past commit requests, it must proceed with evaluating and - applying the changes as normal, except it should not change the current - state of the zwp_text_input_v3 object. All pending state requests - (set_surrounding_text, set_content_type and set_cursor_rectangle) on - the zwp_text_input_v3 object should be sent and committed after - receiving a zwp_text_input_v3.done event with a matching serial. + number of past commit requests, it must proceed as normal, except it + should not change the current state of the zwp_text_input_v3 object. </description> <arg name="serial" type="uint"/> </event>
[-] [+]	Deleted	_service:tar_git:wayland-protocols-1.31.0+git1.tar.xz/wayland-protocols/.gitlab-ci/debian-install.sh ^
@@ -1,14 +0,0 @@ -#!/bin/sh -eux - -# Note: don't forget to bump FDO_DISTRIBUTION_TAG when editing this file! - -git clone --branch 1.20.0 --depth=1 https://gitlab.freedesktop.org/wayland/wayland -cd wayland/ -git show -s HEAD -meson build/ -Dtests=false -Ddocumentation=false -ninja -j${FDO_CI_CONCURRENT:-4} -C build/ install -cd .. -rm -rf wayland/ - -echo "/usr/local/lib" >/etc/ld.so.conf.d/local.conf -ldconfig
[-] [+]	Deleted	_service:tar_git:wayland-protocols-1.31.0+git1.tar.xz/wayland-protocols/staging/content-type/README ^
@@ -1,5 +0,0 @@ -Content type hint protocol - -Maintainers: -Emmanuel Gil Peyrot <linkmauve@linkmauve.fr> -Xaver Hugl <xaver.hugl@gmail.com>
[-] [+]	Deleted	_service:tar_git:wayland-protocols-1.31.0+git1.tar.xz/wayland-protocols/staging/content-type/content-type-v1.xml ^
@@ -1,128 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="content_type_v1"> - <copyright> - Copyright © 2021 Emmanuel Gil Peyrot - Copyright © 2022 Xaver Hugl - - Permission is hereby granted, free of charge, to any person obtaining a - copy of this software and associated documentation files (the "Software"), - to deal in the Software without restriction, including without limitation - the rights to use, copy, modify, merge, publish, distribute, sublicense, - and/or sell copies of the Software, and to permit persons to whom the - Software is furnished to do so, subject to the following conditions: - - The above copyright notice and this permission notice (including the next - paragraph) shall be included in all copies or substantial portions of the - Software. - - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - DEALINGS IN THE SOFTWARE. - </copyright> - - <interface name="wp_content_type_manager_v1" version="1"> - <description summary="surface content type manager"> - This interface allows a client to describe the kind of content a surface - will display, to allow the compositor to optimize its behavior for it. - - Warning! The protocol described in this file is currently in the testing - phase. Backward compatible changes may be added together with the - corresponding interface version bump. Backward incompatible changes can - only be done by creating a new major version of the extension. - </description> - - <request name="destroy" type="destructor"> - <description summary="destroy the content type manager object"> - Destroy the content type manager. This doesn't destroy objects created - with the manager. - </description> - </request> - - <enum name="error"> - <entry name="already_constructed" value="0" - summary="wl_surface already has a content type object"/> - </enum> - - <request name="get_surface_content_type"> - <description summary="create a new toplevel decoration object"> - Create a new content type object associated with the given surface. - - Creating a wp_content_type_v1 from a wl_surface which already has one - attached is a client error: already_constructed. - </description> - <arg name="id" type="new_id" interface="wp_content_type_v1"/> - <arg name="surface" type="object" interface="wl_surface"/> - </request> - </interface> - - <interface name="wp_content_type_v1" version="1"> - <description summary="content type object for a surface"> - The content type object allows the compositor to optimize for the kind - of content shown on the surface. A compositor may for example use it to - set relevant drm properties like "content type". - - The client may request to switch to another content type at any time. - When the associated surface gets destroyed, this object becomes inert and - the client should destroy it. - </description> - - <request name="destroy" type="destructor"> - <description summary="destroy the content type object"> - Switch back to not specifying the content type of this surface. This is - equivalent to setting the content type to none, including double - buffering semantics. See set_content_type for details. - </description> - </request> - - <enum name="type"> - <description summary="possible content types"> - These values describe the available content types for a surface. - </description> - <entry name="none" value="0"> - <description summary="no content type applies"> - The content type none means that either the application has no data - about the content type, or that the content doesn't fit into one of - the other categories. - </description> - </entry> - <entry name="photo" value="1"> - <description summary="photo content type"> - The content type photo describes content derived from digital still - pictures and may be presented with minimal processing. - </description> - </entry> - <entry name="video" value="2"> - <description summary="video content type"> - The content type video describes a video or animation and may be - presented with more accurate timing to avoid stutter. Where scaling - is needed, scaling methods more appropriate for video may be used. - </description> - </entry> - <entry name="game" value="3"> - <description summary="game content type"> - The content type game describes a running game. Its content may be - presented with reduced latency. - </description> - </entry> - </enum> - - <request name="set_content_type"> - <description summary="specify the content type"> - Set the surface content type. This informs the compositor that the - client believes it is displaying buffers matching this content type. - - This is purely a hint for the compositor, which can be used to adjust - its behavior or hardware settings to fit the presented content best. - - The content type is double-buffered state, see wl_surface.commit for - details. - </description> - <arg name="content_type" type="uint" enum="type" - summary="the content type"/> - </request> - </interface> -</protocol>
[-] [+]	Deleted	_service:tar_git:wayland-protocols-1.31.0+git1.tar.xz/wayland-protocols/staging/ext-idle-notify/README ^
@@ -1,4 +0,0 @@ -idle_notify protocol - -Maintainers: -Simon Ser <contact@emersion.fr>
[-] [+]	Deleted	_service:tar_git:wayland-protocols-1.31.0+git1.tar.xz/wayland-protocols/staging/ext-idle-notify/ext-idle-notify-v1.xml ^
@@ -1,102 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="ext_idle_notify_v1"> - <copyright> - Copyright © 2015 Martin Gräßlin - Copyright © 2022 Simon Ser - - Permission is hereby granted, free of charge, to any person obtaining a - copy of this software and associated documentation files (the "Software"), - to deal in the Software without restriction, including without limitation - the rights to use, copy, modify, merge, publish, distribute, sublicense, - and/or sell copies of the Software, and to permit persons to whom the - Software is furnished to do so, subject to the following conditions: - - The above copyright notice and this permission notice (including the next - paragraph) shall be included in all copies or substantial portions of the - Software. - - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - DEALINGS IN THE SOFTWARE. - </copyright> - - <interface name="ext_idle_notifier_v1" version="1"> - <description summary="idle notification manager"> - This interface allows clients to monitor user idle status. - - After binding to this global, clients can create ext_idle_notification_v1 - objects to get notified when the user is idle for a given amount of time. - </description> - - <request name="destroy" type="destructor"> - <description summary="destroy the manager"> - Destroy the manager object. All objects created via this interface - remain valid. - </description> - </request> - - <request name="get_idle_notification"> - <description summary="create a notification object"> - Create a new idle notification object. - - The notification object has a minimum timeout duration and is tied to a - seat. The client will be notified if the seat is inactive for at least - the provided timeout. See ext_idle_notification_v1 for more details. - - A zero timeout is valid and means the client wants to be notified as - soon as possible when the seat is inactive. - </description> - <arg name="id" type="new_id" interface="ext_idle_notification_v1"/> - <arg name="timeout" type="uint" summary="minimum idle timeout in msec"/> - <arg name="seat" type="object" interface="wl_seat"/> - </request> - </interface> - - <interface name="ext_idle_notification_v1" version="1"> - <description summary="idle notification"> - This interface is used by the compositor to send idle notification events - to clients. - - Initially the notification object is not idle. The notification object - becomes idle when no user activity has happened for at least the timeout - duration, starting from the creation of the notification object. User - activity may include input events or a presence sensor, but is - compositor-specific. If an idle inhibitor is active (e.g. another client - has created a zwp_idle_inhibitor_v1 on a visible surface), the compositor - must not make the notification object idle. - - When the notification object becomes idle, an idled event is sent. When - user activity starts again, the notification object stops being idle, - a resumed event is sent and the timeout is restarted. - </description> - - <request name="destroy" type="destructor"> - <description summary="destroy the notification object"> - Destroy the notification object. - </description> - </request> - - <event name="idled"> - <description summary="notification object is idle"> - This event is sent when the notification object becomes idle. - - It's a compositor protocol error to send this event twice without a - resumed event in-between. - </description> - </event> - - <event name="resumed"> - <description summary="notification object is no longer idle"> - This event is sent when the notification object stops being idle. - - It's a compositor protocol error to send this event twice without an - idled event in-between. It's a compositor protocol error to send this - event prior to any idled event. - </description> - </event> - </interface> -</protocol>
[-] [+]	Deleted	_service:tar_git:wayland-protocols-1.31.0+git1.tar.xz/wayland-protocols/staging/ext-session-lock/README ^
@@ -1,4 +0,0 @@ -ext session lock protocol - -Maintainers: -Isaac Freund <mail@isaacfreund.com>
[-] [+]	Deleted	_service:tar_git:wayland-protocols-1.31.0+git1.tar.xz/wayland-protocols/staging/ext-session-lock/ext-session-lock-v1.xml ^
@@ -1,290 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="ext_session_lock_v1"> - <copyright> - Copyright 2021 Isaac Freund - - Permission to use, copy, modify, and/or distribute this software for any - purpose with or without fee is hereby granted, provided that the above - copyright notice and this permission notice appear in all copies. - - THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES - WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF - MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR - ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES - WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN - ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF - OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. - </copyright> - - <description summary="secure session locking with arbitrary graphics"> - This protocol allows for a privileged Wayland client to lock the session - and display arbitrary graphics while the session is locked. - - The compositor may choose to restrict this protocol to a special client - launched by the compositor itself or expose it to all privileged clients, - this is compositor policy. - - The client is responsible for performing authentication and informing the - compositor when the session should be unlocked. If the client dies while - the session is locked the session remains locked, possibly permanently - depending on compositor policy. - - Warning! The protocol described in this file is currently in the - testing phase. Backward compatible changes may be added together with - the corresponding interface version bump. Backward incompatible changes - can only be done by creating a new major version of the extension. - </description> - - <interface name="ext_session_lock_manager_v1" version="1"> - <description summary="used to lock the session"> - This interface is used to request that the session be locked. - </description> - - <request name="destroy" type="destructor"> - <description summary="destroy the session lock manager object"> - This informs the compositor that the session lock manager object will - no longer be used. Existing objects created through this interface - remain valid. - </description> - </request> - - <request name="lock"> - <description summary="attempt to lock the session"> - This request creates a session lock and asks the compositor to lock the - session. The compositor will send either the ext_session_lock_v1.locked - or ext_session_lock_v1.finished event on the created object in - response to this request. - </description> - <arg name="id" type="new_id" interface="ext_session_lock_v1"/> - </request> - </interface> - - <interface name="ext_session_lock_v1" version="1"> - <description summary="manage lock state and create lock surfaces"> - On creation of this object either the locked or finished event will - immediately be sent. - - The locked event indicates that the session is locked. This means that - the compositor should stop rendering and providing input to normal - clients. Instead the compositor should blank all outputs with an opaque - color such that their normal content is fully hidden. - - The only surfaces that should be rendered while the session is locked - are the lock surfaces created through this interface and optionally, - at the compositor's discretion, special privileged surfaces such as - input methods or portions of desktop shell UIs. - - If the client dies while the session is locked, the compositor should not - unlock the session in response. It is acceptable for the session to be - permanently locked if this happens. The compositor may choose to continue - to display the lock surfaces the client had mapped before it died or - alternatively fall back to a solid color, this is compositor policy. - - Compositors may also allow a secure way to recover the session, the - details of this are compositor policy. Compositors may allow a new - client to create a ext_session_lock_v1 object and take responsibility - for unlocking the session, they may even start a new lock client - instance automatically. - </description> - - <enum name="error"> - <entry name="invalid_destroy" value="0" - summary="attempted to destroy session lock while locked"/> - <entry name="invalid_unlock" value="1" - summary="unlock requested but locked event was never sent"/> - <entry name="role" value="2" - summary="given wl_surface already has a role"/> - <entry name="duplicate_output" value="3" - summary="given output already has a lock surface"/> - <entry name="already_constructed" value="4" - summary="given wl_surface has a buffer attached or committed"/> - </enum> - - <request name="destroy" type="destructor"> - <description summary="destroy the session lock"> - This informs the compositor that the lock object will no longer be - used. Existing objects created through this interface remain valid. - - After this request is made, lock surfaces created through this object - should be destroyed by the client as they will no longer be used by - the compositor. - - It is a protocol error to make this request if the locked event was - sent, the unlock_and_destroy request must be used instead. - </description> - </request> - - <event name="locked"> - <description summary="session successfully locked"> - This client is now responsible for displaying graphics while the - session is locked and deciding when to unlock the session. - - Either this event or the finished event will be sent immediately on - creation of this object. - - If this event is sent, making the destroy request is a protocol error, - the lock object may only be destroyed using the unlock_and_destroy - request. - </description> - </event> - - <event name="finished"> - <description summary="the session lock object should be destroyed"> - The compositor has decided that the session lock should be - destroyed. Exactly when this event is sent is compositor policy, but - it will never be sent more than once for a given session lock object. - - This might be sent because there is already another ext_session_lock_v1 - object held by a client, or the compositor has decided to deny the - request to lock the session for some other reason. This might also - be sent because the compositor implements some alternative, secure - way to authenticate and unlock the session. - - Either this event or the locked event will be sent exactly once on - creation of this object. If the locked event is sent on creation of - this object, the finished event may still be sent at some later time - in this object's lifetime, this is compositor policy. - - Upon receiving this event, the client should make either the destroy - request or the unlock_and_destroy request, depending on whether or - not the locked event was received on this object. - </description> - </event> - - <request name="get_lock_surface"> - <description summary="create a lock surface for a given output"> - The client is expected to create lock surfaces for all outputs - currently present and any new outputs as they are advertised. These - won't be displayed by the compositor unless the lock is successful - and the locked event is sent. - - Providing a wl_surface which already has a role or already has a buffer - attached or committed is a protocol error, as is attaching/committing - a buffer before the first ext_session_lock_surface_v1.configure event. - - Attempting to create more than one lock surface for a given output - is a duplicate_output protocol error. - </description> - <arg name="id" type="new_id" interface="ext_session_lock_surface_v1"/> - <arg name="surface" type="object" interface="wl_surface"/> - <arg name="output" type="object" interface="wl_output"/> - </request> - - <request name="unlock_and_destroy" type="destructor"> - <description summary="unlock the session, destroying the object"> - This request indicates that the session should be unlocked, for - example because the user has entered their password and it has been - verified by the client. - - This request also informs the compositor that the lock object will - no longer be used and may be safely destroyed. Existing objects - created through this interface remain valid. - - After this request is made, lock surfaces created through this object - should be destroyed by the client as they will no longer be used by - the compositor. - - It is a protocol error to make this request if the locked event has - not been sent. In that case, the lock object may only be destroyed - using the destroy request. - - Note that a correct client that wishes to exit directly after unlocking - the session must use the wl_display.sync request to ensure the server - receives and processes the unlock_and_destroy request. Otherwise - there is no guarantee that the server has unlocked the session due - to the asynchronous nature of the Wayland protocol. For example, - the server might terminate the client with a protocol error before - it processes the unlock_and_destroy request. - </description> - </request>
[-] [+]	Deleted	_service:tar_git:wayland-protocols-1.31.0+git1.tar.xz/wayland-protocols/staging/fractional-scale/README ^
@@ -1,4 +0,0 @@ -wp fractional scale protocol - -Maintainers: -Kenny Levinsen <kl@kl.wtf>
[-] [+]	Deleted	_service:tar_git:wayland-protocols-1.31.0+git1.tar.xz/wayland-protocols/staging/fractional-scale/fractional-scale-v1.xml ^
@@ -1,102 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="fractional_scale_v1"> - <copyright> - Copyright © 2022 Kenny Levinsen - - Permission is hereby granted, free of charge, to any person obtaining a - copy of this software and associated documentation files (the "Software"), - to deal in the Software without restriction, including without limitation - the rights to use, copy, modify, merge, publish, distribute, sublicense, - and/or sell copies of the Software, and to permit persons to whom the - Software is furnished to do so, subject to the following conditions: - - The above copyright notice and this permission notice (including the next - paragraph) shall be included in all copies or substantial portions of the - Software. - - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - DEALINGS IN THE SOFTWARE. - </copyright> - - <description summary="Protocol for requesting fractional surface scales"> - This protocol allows a compositor to suggest for surfaces to render at - fractional scales. - - A client can submit scaled content by utilizing wp_viewport. This is done by - creating a wp_viewport object for the surface and setting the destination - rectangle to the surface size before the scale factor is applied. - - The buffer size is calculated by multiplying the surface size by the - intended scale. - - The wl_surface buffer scale should remain set to 1. - - If a surface has a surface-local size of 100 px by 50 px and wishes to - submit buffers with a scale of 1.5, then a buffer of 150px by 75 px should - be used and the wp_viewport destination rectangle should be 100 px by 50 px. - - For toplevel surfaces, the size is rounded halfway away from zero. The - rounding algorithm for subsurface position and size is not defined. - </description> - - <interface name="wp_fractional_scale_manager_v1" version="1"> - <description summary="fractional surface scale information"> - A global interface for requesting surfaces to use fractional scales. - </description> - - <request name="destroy" type="destructor"> - <description summary="unbind the fractional surface scale interface"> - Informs the server that the client will not be using this protocol - object anymore. This does not affect any other objects, - wp_fractional_scale_v1 objects included. - </description> - </request> - - <enum name="error"> - <entry name="fractional_scale_exists" value="0" - summary="the surface already has a fractional_scale object associated"/> - </enum> - - <request name="get_fractional_scale"> - <description summary="extend surface interface for scale information"> - Create an add-on object for the the wl_surface to let the compositor - request fractional scales. If the given wl_surface already has a - wp_fractional_scale_v1 object associated, the fractional_scale_exists - protocol error is raised. - </description> - <arg name="id" type="new_id" interface="wp_fractional_scale_v1" - summary="the new surface scale info interface id"/> - <arg name="surface" type="object" interface="wl_surface" - summary="the surface"/> - </request> - </interface> - - <interface name="wp_fractional_scale_v1" version="1"> - <description summary="fractional scale interface to a wl_surface"> - An additional interface to a wl_surface object which allows the compositor - to inform the client of the preferred scale. - </description> - - <request name="destroy" type="destructor"> - <description summary="remove surface scale information for surface"> - Destroy the fractional scale object. When this object is destroyed, - preferred_scale events will no longer be sent. - </description> - </request> - - <event name="preferred_scale"> - <description summary="notify of new preferred scale"> - Notification of a new preferred scale for this surface that the - compositor suggests that the client should use. - - The sent scale is the numerator of a fraction with a denominator of 120. - </description> - <arg name="scale" type="uint" summary="the new preferred scale"/> - </event> - </interface> -</protocol>
[-] [+]	Deleted	_service:tar_git:wayland-protocols-1.31.0+git1.tar.xz/wayland-protocols/staging/single-pixel-buffer/README ^
@@ -1,4 +0,0 @@ -Single-pixel buffer protocol - -Maintainers: -Simon Ser <contact@emersion.fr>
[-] [+]	Deleted	_service:tar_git:wayland-protocols-1.31.0+git1.tar.xz/wayland-protocols/staging/single-pixel-buffer/single-pixel-buffer-v1.xml ^
@@ -1,69 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="single_pixel_buffer_v1"> - <copyright> - Copyright © 2022 Simon Ser - - Permission is hereby granted, free of charge, to any person obtaining a - copy of this software and associated documentation files (the "Software"), - to deal in the Software without restriction, including without limitation - the rights to use, copy, modify, merge, publish, distribute, sublicense, - and/or sell copies of the Software, and to permit persons to whom the - Software is furnished to do so, subject to the following conditions: - - The above copyright notice and this permission notice (including the next - paragraph) shall be included in all copies or substantial portions of the - Software. - - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - DEALINGS IN THE SOFTWARE. - </copyright> - - <description summary="single pixel buffer factory"> - This protocol extension allows clients to create single-pixel buffers. - - Compositors supporting this protocol extension should also support the - viewporter protocol extension. Clients may use viewporter to scale a - single-pixel buffer to a desired size. - - Warning! The protocol described in this file is currently in the testing - phase. Backward compatible changes may be added together with the - corresponding interface version bump. Backward incompatible changes can - only be done by creating a new major version of the extension. - </description> - - <interface name="wp_single_pixel_buffer_manager_v1" version="1"> - <description summary="global factory for single-pixel buffers"> - The wp_single_pixel_buffer_manager_v1 interface is a factory for - single-pixel buffers. - </description> - - <request name="destroy" type="destructor"> - <description summary="destroy the manager"> - Destroy the wp_single_pixel_buffer_manager_v1 object. - - The child objects created via this interface are unaffected. - </description> - </request> - - <request name="create_u32_rgba_buffer"> - <description summary="create a 1×1 buffer from 32-bit RGBA values"> - Create a single-pixel buffer from four 32-bit RGBA values. - - Unless specified in another protocol extension, the RGBA values use - pre-multiplied alpha. - - The width and height of the buffer are 1. - </description> - <arg name="id" type="new_id" interface="wl_buffer"/> - <arg name="r" type="uint" summary="value of the buffer's red channel"/> - <arg name="g" type="uint" summary="value of the buffer's green channel"/> - <arg name="b" type="uint" summary="value of the buffer's blue channel"/> - <arg name="a" type="uint" summary="value of the buffer's alpha channel"/> - </request> - </interface> -</protocol>
[-] [+]	Deleted	_service:tar_git:wayland-protocols-1.31.0+git1.tar.xz/wayland-protocols/staging/tearing-control/README ^
@@ -1,4 +0,0 @@ -Tearing control protocol - -Maintainers: -Xaver Hugl <xaver.hugl@gmail.com>
[-] [+]	Deleted	_service:tar_git:wayland-protocols-1.31.0+git1.tar.xz/wayland-protocols/staging/tearing-control/tearing-control-v1.xml ^
@@ -1,120 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="tearing_control_v1"> - <copyright> - Copyright © 2021 Xaver Hugl - - Permission is hereby granted, free of charge, to any person obtaining a - copy of this software and associated documentation files (the "Software"), - to deal in the Software without restriction, including without limitation - the rights to use, copy, modify, merge, publish, distribute, sublicense, - and/or sell copies of the Software, and to permit persons to whom the - Software is furnished to do so, subject to the following conditions: - - The above copyright notice and this permission notice (including the next - paragraph) shall be included in all copies or substantial portions of the - Software. - - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - DEALINGS IN THE SOFTWARE. - </copyright> - - <interface name="wp_tearing_control_manager_v1" version="1"> - <description summary="protocol for tearing control"> - For some use cases like games or drawing tablets it can make sense to - reduce latency by accepting tearing with the use of asynchronous page - flips. This global is a factory interface, allowing clients to inform - which type of presentation the content of their surfaces is suitable for. - - Graphics APIs like EGL or Vulkan, that manage the buffer queue and commits - of a wl_surface themselves, are likely to be using this extension - internally. If a client is using such an API for a wl_surface, it should - not directly use this extension on that surface, to avoid raising a - tearing_control_exists protocol error. - - Warning! The protocol described in this file is currently in the testing - phase. Backward compatible changes may be added together with the - corresponding interface version bump. Backward incompatible changes can - only be done by creating a new major version of the extension. - </description> - - <request name="destroy" type="destructor"> - <description summary="destroy tearing control factory object"> - Destroy this tearing control factory object. Other objects, including - wp_tearing_control_v1 objects created by this factory, are not affected - by this request. - </description> - </request> - - <enum name="error"> - <entry name="tearing_control_exists" value="0" - summary="the surface already has a tearing object associated"/> - </enum> - - <request name="get_tearing_control"> - <description summary="extend surface interface for tearing control"> - Instantiate an interface extension for the given wl_surface to request - asynchronous page flips for presentation. - - If the given wl_surface already has a wp_tearing_control_v1 object - associated, the tearing_control_exists protocol error is raised. - </description> - <arg name="id" type="new_id" interface="wp_tearing_control_v1"/> - <arg name="surface" type="object" interface="wl_surface"/> - </request> - </interface> - - <interface name="wp_tearing_control_v1" version="1"> - <description summary="per-surface tearing control interface"> - An additional interface to a wl_surface object, which allows the client - to hint to the compositor if the content on the surface is suitable for - presentation with tearing. - The default presentation hint is vsync. See presentation_hint for more - details. - </description> - - <enum name="presentation_hint"> - <description summary="presentation hint values"> - This enum provides information for if submitted frames from the client - may be presented with tearing. - </description> - <entry name="vsync" value="0"> - <description summary="tearing-free presentation"> - The content of this surface is meant to be synchronized to the - vertical blanking period. This should not result in visible tearing - and may result in a delay before a surface commit is presented. - </description> - </entry> - <entry name="async" value="1"> - <description summary="asynchronous presentation"> - The content of this surface is meant to be presented with minimal - latency and tearing is acceptable. - </description> - </entry> - </enum> - - <request name="set_presentation_hint"> - <description summary="set presentation hint"> - Set the presentation hint for the associated wl_surface. This state is - double-buffered and is applied on the next wl_surface.commit. - - The compositor is free to dynamically respect or ignore this hint based - on various conditions like hardware capabilities, surface state and - user preferences. - </description> - <arg name="hint" type="uint" enum="presentation_hint"/> - </request> - - <request name="destroy" type="destructor"> - <description summary="destroy tearing control object"> - Destroy this surface tearing object and revert the presentation hint to - vsync. The change will be applied on the next wl_surface.commit. - </description> - </request> - </interface> - -</protocol>
[-] [+]	Deleted	_service:tar_git:wayland-protocols-1.31.0+git1.tar.xz/wayland-protocols/staging/xwayland-shell/README ^
@@ -1,4 +0,0 @@ -Xwayland shell protocol - -Maintainers: -Joshua Ashton <joshua@froggi.es>
[-] [+]	Deleted	_service:tar_git:wayland-protocols-1.31.0+git1.tar.xz/wayland-protocols/staging/xwayland-shell/xwayland-shell-v1.xml ^
@@ -1,162 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<protocol name="xwayland_shell_v1"> - - <copyright> - Copyright © 2022 Joshua Ashton - - Permission is hereby granted, free of charge, to any person obtaining a - copy of this software and associated documentation files (the "Software"), - to deal in the Software without restriction, including without limitation - the rights to use, copy, modify, merge, publish, distribute, sublicense, - and/or sell copies of the Software, and to permit persons to whom the - Software is furnished to do so, subject to the following conditions: - - The above copyright notice and this permission notice (including the next - paragraph) shall be included in all copies or substantial portions of the - Software. - - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - DEALINGS IN THE SOFTWARE. - </copyright> - - <description summary="Protocol for associating X11 windows to wl_surfaces"> - This protocol adds a xwayland_surface role which allows an Xwayland - server to associate an X11 window to a wl_surface. - - Before this protocol, this would be done via the Xwayland server - providing the wl_surface's resource id via the a client message with - the WL_SURFACE_ID atom on the X window. - This was problematic as a race could occur if the wl_surface - associated with a WL_SURFACE_ID for a window was destroyed before the - client message was processed by the compositor and another surface - (or other object) had taken its id due to recycling. - - This protocol solves the problem by moving the X11 window to wl_surface - association step to the Wayland side, which means that the association - cannot happen out-of-sync with the resource lifetime of the wl_surface. - - This protocol avoids duplicating the race on the other side by adding a - non-zero monotonic serial number which is entirely unique that is set on - both the wl_surface (via. xwayland_surface_v1's set_serial method) and - the X11 window (via. the `WL_SURFACE_SERIAL` client message) that can be - used to associate them, and synchronize the two timelines. - - The key words "must", "must not", "required", "shall", "shall not", - "should", "should not", "recommended", "may", and "optional" in this - document are to be interpreted as described in IETF RFC 2119. - - Warning! The protocol described in this file is currently in the testing - phase. Backward compatible changes may be added together with the - corresponding interface version bump. Backward incompatible changes can - only be done by creating a new major version of the extension. - </description> - - <interface name="xwayland_shell_v1" version="1"> - <description summary="context object for Xwayland shell"> - xwayland_shell_v1 is a singleton global object that - provides the ability to create a xwayland_surface_v1 object - for a given wl_surface. - - This interface is intended to be bound by the Xwayland server. - - A compositor must not allow clients other than Xwayland to - bind to this interface. A compositor should hide this global - from other clients' wl_registry. - A client the compositor does not consider to be an Xwayland - server attempting to bind this interface will result in - an implementation-defined error. - - An Xwayland server that has bound this interface must not - set the `WL_SURFACE_ID` atom on a window. - </description> - - <enum name="error"> - <entry name="role" value="0" summary="given wl_surface has another role"/> - </enum> - - <request name="destroy" type="destructor"> - <description summary="destroy the Xwayland shell object"> - Destroy the xwayland_shell_v1 object. - - The child objects created via this interface are unaffected. - </description> - </request> - - <request name="get_xwayland_surface"> - <description summary="assign the xwayland_surface surface role"> - Create an xwayland_surface_v1 interface for a given wl_surface - object and gives it the xwayland_surface role. - - It is illegal to create an xwayland_surface_v1 for a wl_surface - which already has an assigned role and this will result in the - `role` protocol error. - - See the documentation of xwayland_surface_v1 for more details - about what an xwayland_surface_v1 is and how it is used. - </description> - - <arg name="id" type="new_id" interface="xwayland_surface_v1"/> - <arg name="surface" type="object" interface="wl_surface"/> - </request> - </interface> - - <interface name="xwayland_surface_v1" version="1"> - <description summary="interface for associating Xwayland windows to wl_surfaces"> - An Xwayland surface is a surface managed by an Xwayland server. - It is used for associating surfaces to Xwayland windows. - - The Xwayland server associated with actions in this interface is - determined by the Wayland client making the request. - - The client must call wl_surface.commit on the corresponding wl_surface - for the xwayland_surface_v1 state to take effect. - </description> - - <enum name="error"> - <entry name="already_associated" value="0" summary="given wl_surface is already associated with an X11 window"/> - <entry name="invalid_serial" value="1" summary="serial was not valid"/> - </enum> - - <request name="set_serial"> - <description summary="associates a Xwayland window to a wl_surface"> - Associates an Xwayland window to a wl_surface. - The association state is double-buffered and will be applied at - the time wl_surface.commit of the corresponding wl_surface is called. - - The `serial_lo` and `serial_hi` parameters specify a non-zero - monotonic serial number which is entirely unique and provided by the - Xwayland server equal to the serial value provided by a client message - with a message type of the `WL_SURFACE_SERIAL` atom on the X11 window - for this surface to be associated to. - - The serial value in the `WL_SURFACE_SERIAL` client message is specified - as having the lo-bits specified in `l[0]` and the hi-bits specified - in `l[1]`. - - If the serial value provided by `serial_lo` and `serial_hi` is not - valid, the `invalid_serial` protocol error will be raised. - - An X11 window may be associated with multiple surfaces throughout its - lifespan. (eg. unmapping and remapping a window). - - For each wl_surface, this state must not be committed more than once, - otherwise the `already_associated` protocol error will be raised. - </description> - <arg name="serial_lo" type="uint" summary="The lower 32-bits of the serial number associated with the X11 window"/> - <arg name="serial_hi" type="uint" summary="The upper 32-bits of the serial number associated with the X11 window"/> - </request> - - <request name="destroy" type="destructor"> - <description summary="destroy the Xwayland surface object"> - Destroy the xwayland_surface_v1 object. - - Any already existing associations are unaffected by this action. - </description> - </request> - </interface> -</protocol>