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