diff options
Diffstat (limited to 'contrib/SDL-3.2.8/wayland-protocols/xdg-output-unstable-v1.xml')
| -rw-r--r-- | contrib/SDL-3.2.8/wayland-protocols/xdg-output-unstable-v1.xml | 220 |
1 files changed, 220 insertions, 0 deletions
diff --git a/contrib/SDL-3.2.8/wayland-protocols/xdg-output-unstable-v1.xml b/contrib/SDL-3.2.8/wayland-protocols/xdg-output-unstable-v1.xml new file mode 100644 index 0000000..9a5b790 --- /dev/null +++ b/contrib/SDL-3.2.8/wayland-protocols/xdg-output-unstable-v1.xml | |||
| @@ -0,0 +1,220 @@ | |||
| 1 | <?xml version="1.0" encoding="UTF-8"?> | ||
| 2 | <protocol name="xdg_output_unstable_v1"> | ||
| 3 | |||
| 4 | <copyright> | ||
| 5 | Copyright © 2017 Red Hat Inc. | ||
| 6 | |||
| 7 | Permission is hereby granted, free of charge, to any person obtaining a | ||
| 8 | copy of this software and associated documentation files (the "Software"), | ||
| 9 | to deal in the Software without restriction, including without limitation | ||
| 10 | the rights to use, copy, modify, merge, publish, distribute, sublicense, | ||
| 11 | and/or sell copies of the Software, and to permit persons to whom the | ||
| 12 | Software is furnished to do so, subject to the following conditions: | ||
| 13 | |||
| 14 | The above copyright notice and this permission notice (including the next | ||
| 15 | paragraph) shall be included in all copies or substantial portions of the | ||
| 16 | Software. | ||
| 17 | |||
| 18 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR | ||
| 19 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, | ||
| 20 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL | ||
| 21 | THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER | ||
| 22 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING | ||
| 23 | FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER | ||
| 24 | DEALINGS IN THE SOFTWARE. | ||
| 25 | </copyright> | ||
| 26 | |||
| 27 | <description summary="Protocol to describe output regions"> | ||
| 28 | This protocol aims at describing outputs in a way which is more in line | ||
| 29 | with the concept of an output on desktop oriented systems. | ||
| 30 | |||
| 31 | Some information are more specific to the concept of an output for | ||
| 32 | a desktop oriented system and may not make sense in other applications, | ||
| 33 | such as IVI systems for example. | ||
| 34 | |||
| 35 | Typically, the global compositor space on a desktop system is made of | ||
| 36 | a contiguous or overlapping set of rectangular regions. | ||
| 37 | |||
| 38 | Some of the information provided in this protocol might be identical | ||
| 39 | to their counterparts already available from wl_output, in which case | ||
| 40 | the information provided by this protocol should be preferred to their | ||
| 41 | equivalent in wl_output. The goal is to move the desktop specific | ||
| 42 | concepts (such as output location within the global compositor space, | ||
| 43 | the connector name and types, etc.) out of the core wl_output protocol. | ||
| 44 | |||
| 45 | Warning! The protocol described in this file is experimental and | ||
| 46 | backward incompatible changes may be made. Backward compatible | ||
| 47 | changes may be added together with the corresponding interface | ||
| 48 | version bump. | ||
| 49 | Backward incompatible changes are done by bumping the version | ||
| 50 | number in the protocol and interface names and resetting the | ||
| 51 | interface version. Once the protocol is to be declared stable, | ||
| 52 | the 'z' prefix and the version number in the protocol and | ||
| 53 | interface names are removed and the interface version number is | ||
| 54 | reset. | ||
| 55 | </description> | ||
| 56 | |||
| 57 | <interface name="zxdg_output_manager_v1" version="3"> | ||
| 58 | <description summary="manage xdg_output objects"> | ||
| 59 | A global factory interface for xdg_output objects. | ||
| 60 | </description> | ||
| 61 | |||
| 62 | <request name="destroy" type="destructor"> | ||
| 63 | <description summary="destroy the xdg_output_manager object"> | ||
| 64 | Using this request a client can tell the server that it is not | ||
| 65 | going to use the xdg_output_manager object anymore. | ||
| 66 | |||
| 67 | Any objects already created through this instance are not affected. | ||
| 68 | </description> | ||
| 69 | </request> | ||
| 70 | |||
| 71 | <request name="get_xdg_output"> | ||
| 72 | <description summary="create an xdg output from a wl_output"> | ||
| 73 | This creates a new xdg_output object for the given wl_output. | ||
| 74 | </description> | ||
| 75 | <arg name="id" type="new_id" interface="zxdg_output_v1"/> | ||
| 76 | <arg name="output" type="object" interface="wl_output"/> | ||
| 77 | </request> | ||
| 78 | </interface> | ||
| 79 | |||
| 80 | <interface name="zxdg_output_v1" version="3"> | ||
| 81 | <description summary="compositor logical output region"> | ||
| 82 | An xdg_output describes part of the compositor geometry. | ||
| 83 | |||
| 84 | This typically corresponds to a monitor that displays part of the | ||
| 85 | compositor space. | ||
| 86 | |||
| 87 | For objects version 3 onwards, after all xdg_output properties have been | ||
| 88 | sent (when the object is created and when properties are updated), a | ||
| 89 | wl_output.done event is sent. This allows changes to the output | ||
| 90 | properties to be seen as atomic, even if they happen via multiple events. | ||
| 91 | </description> | ||
| 92 | |||
| 93 | <request name="destroy" type="destructor"> | ||
| 94 | <description summary="destroy the xdg_output object"> | ||
| 95 | Using this request a client can tell the server that it is not | ||
| 96 | going to use the xdg_output object anymore. | ||
| 97 | </description> | ||
| 98 | </request> | ||
| 99 | |||
| 100 | <event name="logical_position"> | ||
| 101 | <description summary="position of the output within the global compositor space"> | ||
| 102 | The position event describes the location of the wl_output within | ||
| 103 | the global compositor space. | ||
| 104 | |||
| 105 | The logical_position event is sent after creating an xdg_output | ||
| 106 | (see xdg_output_manager.get_xdg_output) and whenever the location | ||
| 107 | of the output changes within the global compositor space. | ||
| 108 | </description> | ||
| 109 | <arg name="x" type="int" | ||
| 110 | summary="x position within the global compositor space"/> | ||
| 111 | <arg name="y" type="int" | ||
| 112 | summary="y position within the global compositor space"/> | ||
| 113 | </event> | ||
| 114 | |||
| 115 | <event name="logical_size"> | ||
| 116 | <description summary="size of the output in the global compositor space"> | ||
| 117 | The logical_size event describes the size of the output in the | ||
| 118 | global compositor space. | ||
| 119 | |||
| 120 | For example, a surface without any buffer scale, transformation | ||
| 121 | nor rotation set, with the size matching the logical_size will | ||
| 122 | have the same size as the corresponding output when displayed. | ||
| 123 | |||
| 124 | Most regular Wayland clients should not pay attention to the | ||
| 125 | logical size and would rather rely on xdg_shell interfaces. | ||
| 126 | |||
| 127 | Some clients such as Xwayland, however, need this to configure | ||
| 128 | their surfaces in the global compositor space as the compositor | ||
| 129 | may apply a different scale from what is advertised by the output | ||
| 130 | scaling property (to achieve fractional scaling, for example). | ||
| 131 | |||
| 132 | For example, for a wl_output mode 3840×2160 and a scale factor 2: | ||
| 133 | |||
| 134 | - A compositor not scaling the surface buffers will advertise a | ||
| 135 | logical size of 3840×2160, | ||
| 136 | |||
| 137 | - A compositor automatically scaling the surface buffers will | ||
| 138 | advertise a logical size of 1920×1080, | ||
| 139 | |||
| 140 | - A compositor using a fractional scale of 1.5 will advertise a | ||
| 141 | logical size of 2560×1440. | ||
| 142 | |||
| 143 | For example, for a wl_output mode 1920×1080 and a 90 degree rotation, | ||
| 144 | the compositor will advertise a logical size of 1080x1920. | ||
| 145 | |||
| 146 | The logical_size event is sent after creating an xdg_output | ||
| 147 | (see xdg_output_manager.get_xdg_output) and whenever the logical | ||
| 148 | size of the output changes, either as a result of a change in the | ||
| 149 | applied scale or because of a change in the corresponding output | ||
| 150 | mode(see wl_output.mode) or transform (see wl_output.transform). | ||
| 151 | </description> | ||
| 152 | <arg name="width" type="int" | ||
| 153 | summary="width in global compositor space"/> | ||
| 154 | <arg name="height" type="int" | ||
| 155 | summary="height in global compositor space"/> | ||
| 156 | </event> | ||
| 157 | |||
| 158 | <event name="done"> | ||
| 159 | <description summary="all information about the output have been sent"> | ||
| 160 | This event is sent after all other properties of an xdg_output | ||
| 161 | have been sent. | ||
| 162 | |||
| 163 | This allows changes to the xdg_output properties to be seen as | ||
| 164 | atomic, even if they happen via multiple events. | ||
| 165 | |||
| 166 | For objects version 3 onwards, this event is deprecated. Compositors | ||
| 167 | are not required to send it anymore and must send wl_output.done | ||
| 168 | instead. | ||
| 169 | </description> | ||
| 170 | </event> | ||
| 171 | |||
| 172 | <!-- Version 2 additions --> | ||
| 173 | |||
| 174 | <event name="name" since="2"> | ||
| 175 | <description summary="name of this output"> | ||
| 176 | Many compositors will assign names to their outputs, show them to the | ||
| 177 | user, allow them to be configured by name, etc. The client may wish to | ||
| 178 | know this name as well to offer the user similar behaviors. | ||
| 179 | |||
| 180 | The naming convention is compositor defined, but limited to | ||
| 181 | alphanumeric characters and dashes (-). Each name is unique among all | ||
| 182 | wl_output globals, but if a wl_output global is destroyed the same name | ||
| 183 | may be reused later. The names will also remain consistent across | ||
| 184 | sessions with the same hardware and software configuration. | ||
| 185 | |||
| 186 | Examples of names include 'HDMI-A-1', 'WL-1', 'X11-1', etc. However, do | ||
| 187 | not assume that the name is a reflection of an underlying DRM | ||
| 188 | connector, X11 connection, etc. | ||
| 189 | |||
| 190 | The name event is sent after creating an xdg_output (see | ||
| 191 | xdg_output_manager.get_xdg_output). This event is only sent once per | ||
| 192 | xdg_output, and the name does not change over the lifetime of the | ||
| 193 | wl_output global. | ||
| 194 | </description> | ||
| 195 | <arg name="name" type="string" summary="output name"/> | ||
| 196 | </event> | ||
| 197 | |||
| 198 | <event name="description" since="2"> | ||
| 199 | <description summary="human-readable description of this output"> | ||
| 200 | Many compositors can produce human-readable descriptions of their | ||
| 201 | outputs. The client may wish to know this description as well, to | ||
| 202 | communicate the user for various purposes. | ||
| 203 | |||
| 204 | The description is a UTF-8 string with no convention defined for its | ||
| 205 | contents. Examples might include 'Foocorp 11" Display' or 'Virtual X11 | ||
| 206 | output via :1'. | ||
| 207 | |||
| 208 | The description event is sent after creating an xdg_output (see | ||
| 209 | xdg_output_manager.get_xdg_output) and whenever the description | ||
| 210 | changes. The description is optional, and may not be sent at all. | ||
| 211 | |||
| 212 | For objects of version 2 and lower, this event is only sent once per | ||
| 213 | xdg_output, and the description does not change over the lifetime of | ||
| 214 | the wl_output global. | ||
| 215 | </description> | ||
| 216 | <arg name="description" type="string" summary="output description"/> | ||
| 217 | </event> | ||
| 218 | |||
| 219 | </interface> | ||
| 220 | </protocol> | ||
