dlls/winewayland.drv/xdg-output-unstable-v1.xml

   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>