protocol/agl-shell.xml

   1 <?xml version="1.0" encoding="UTF-8"?>
   2 <protocol name="agl_shell">
   3   <copyright>
   4     Copyright © 2019, 2022 Collabora, Ltd.
   5
   6     Permission is hereby granted, free of charge, to any person obtaining a
   7     copy of this software and associated documentation files (the "Software"),
   8     to deal in the Software without restriction, including without limitation
   9     the rights to use, copy, modify, merge, publish, distribute, sublicense,
  10     and/or sell copies of the Software, and to permit persons to whom the
  11     Software is furnished to do so, subject to the following conditions:
  12
  13     The above copyright notice and this permission notice (including the next
  14     paragraph) shall be included in all copies or substantial portions of the
  15     Software.
  16
  17     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
  18     IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
  19     FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
  20     THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
  21     LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  22     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
  23     DEALINGS IN THE SOFTWARE.
  24   </copyright>
  25   <interface name="agl_shell" version="3">
  26     <description summary="user interface for Automotive Grade Linux platform">
  27       Starting with version 2 of the protocol, the client is required to wait
  28       for the 'bound_ok' or 'bound_fail' events in order to proceed further.
  29
  30       In case the client gets a 'bound_fail' event then it should consider that
  31       there's another client already bound to the agl_shell protocol.
  32       A client that receives a 'bound_ok' event should consider that there's
  33       no other client already bound to the interface and can proceed further.
  34
  35       If the client uses an older version of the protocol it will receive
  36       automatically an error and the compositor will terminate the connection,
  37       if there's another client already bound the interface.
  38
  39       If the client receives the 'bound_fail' event and attempts to use the
  40       interface further it will receive an error and the compositor will
  41       terminate the connection. After the 'bound_fail' event was received the
  42       client should call the destructor, which has been added with version 2
  43       of the protocol. The client is free to try at a later point in time to
  44       see if it will receive the 'bound_ok' event, but there's no explicit way
  45       of finding out when that event will be delivered.
  46       It is assumed that it can infer that information through other
  47       means/other channels.
  48     </description>
  49
  50     <request name="destroy" type="destructor" since="2">
  51       <description summary="destroys the factory object">
  52       </description>
  53     </request>
  54
  55     <enum name="error">
  56       <entry name="invalid_argument" value="0"/>
  57       <entry name="background_exists" value="1"/>
  58       <entry name="panel_exists" value="2"/>
  59     </enum>
  60
  61     <enum name="edge">
  62       <entry name="top" value="0"/>
  63       <entry name="bottom" value="1"/>
  64       <entry name="left" value="2"/>
  65       <entry name="right" value="3"/>
  66     </enum>
  67
  68     <enum name="tile_orientation" since="3">
  69       <entry name="none" value="0"/>
  70       <entry name="left" value="1"/>
  71       <entry name="right" value="2"/>
  72       <entry name="top" value="3"/>
  73       <entry name="bottom" value="4"/>
  74     </enum>
  75
  76
  77     <request name="ready">
  78       <description summary="client is ready to be shown">
  79         Tell the server that this client is ready to be shown. The server
  80         will delay presentation during start-up until all shell clients are
  81         ready to be shown, and will display a black screen instead.
  82         This gives the client an opportunity to set up and configure several
  83         surfaces into a coherent interface.
  84
  85         The client that binds to this interface must send this request, otherwise
  86         they may stall the compositor unnecessarily.
  87
  88         If this request is called after the compositor has already finished
  89         start-up, no operation is performed.
  90       </description>
  91     </request>
  92
  93     <request name="set_background">
  94       <description summary="set surface as output's background">
  95         Set the surface to act as the background of an output. After this
  96         request, the server will immediately send a configure event with
  97         the dimensions the client should use to cover the entire output.
  98
  99         The surface must have a "desktop" surface role, as supported by
 100         libweston-desktop.
 101
 102         Only a single surface may be the background for any output. If a
 103         background surface already exists, a protocol error is raised.
 104       </description>
 105       <arg name="surface" type="object" interface="wl_surface"/>
 106       <arg name="output" type="object" interface="wl_output"/>
 107     </request>
 108
 109     <request name="set_panel">
 110       <description summary="set surface as panel">
 111         Set the surface to act as a panel of an output. The 'edge' argument
 112         says what edge of the output the surface will be anchored to.
 113         After this request, the server will send a configure event with the
 114         corresponding width/height that the client should use, and 0 for the
 115         other dimension. E.g. if the edge is 'top', the width will be the
 116         output's width, and the height will be 0.
 117
 118         The surface must have a "desktop" surface role, as supported by
 119         libweston-desktop.
 120
 121         The compositor will take the panel's window geometry into account when
 122         positioning other windows, so the panels are not covered.
 123
 124         XXX: What happens if e.g. both top and left are used at the same time?
 125         Who gets to have the corner?
 126
 127         Only a single surface may be the panel for an output's edge. If a
 128         surface already exists on an edge, a protocol error is raised.
 129       </description>
 130       <arg name="surface" type="object" interface="wl_surface"/>
 131       <arg name="output" type="object" interface="wl_output"/>
 132       <arg name="edge" type="uint" enum="edge"/>
 133     </request>
 134
 135     <request name="activate_app">
 136       <description summary="make client current window">
 137         Ask the compositor to make a toplevel to become the current/focused
 138         window for window management purposes.
 139
 140         See xdg_toplevel.set_app_id from the xdg-shell protocol for a
 141         description of app_id.
 142
 143         If multiple toplevels have the same app_id, the result is unspecified.
 144
 145         XXX: Do we need feedback to say it didn't work? (e.g. client does
 146         not exist)
 147       </description>
 148       <arg name="app_id" type="string"/>
 149       <arg name="output" type="object" interface="wl_output"/>
 150     </request>
 151
 152     <event name="bound_ok" since="2">
 153      <description summary="event sent if binding was ok">
 154         Informs the client that it was able to bind the agl_shell
 155         interface succesfully. Clients are required to wait for this
 156         event before continuing further.
 157      </description>
 158     </event>
 159
 160     <event name="bound_fail" since="2">
 161       <description summary="event sent if binding was nok">
 162         Informs the client that binding to the agl_shell interface was
 163         unsuccesfull. Clients are required to wait for this event for
 164         continuing further.
 165       </description>
 166     </event>
 167
 168     <request name="set_app_split" since="3">
 169       <description summary="set the application split">
 170         This requests asks the compositor to change the application from the
 171         original mode (whatever that might be) to a split, tiled orientation
 172         mode defined in the orientation enum.
 173         Clients need to implement resizing (to handle xdg-shell configure
 174         events) for this to work correctly.
 175
 176         This request only handles a single level of tiling for practical
 177         reasons: to keep implementation simple and straight forward. The
 178         compositor will ignore requests if there are already two windows
 179         present. The client can verify this request succeed by checking the
 180         xdg-shell configure event and with it, the states sent
 181         by the compositor.
 182
 183         If there's no app_id with the supplied name, the compositor will add the app
 184         to a pending list in order to be applied when an application gets
 185         started, or if the application sets its application after the initial
 186         wl_surface.commit request.
 187         Applications can use this approach if they want to be started in a
 188         tiled orientation position, before creating the xdg-shell toplevel role.
 189
 190
 191         A none orientation type would make the window go back to the original
 192         maximized mode. If two windows are side by side, returning one of them
 193         back the original mode would mean the other one will be made hidden
 194         and the one doing the request for the none orientation will become
 195         the currently active window. A further activation, using activate_app
 196         request for the other window would make that one active.
 197
 198         Closing the window in the tiled orientation state implies that either
 199         the background surface will displayed, or in case there was another
 200         applications being shown at that time, will make that application be
 201         returned to the original, maximized state.
 202
 203         The tiled orientation could be applied independently of each other,
 204         such that a client can transition from one tiled orientation to
 205         another. Note that any other window already present would literally
 206         take the opposite orientation with the one currently being changed. So
 207         tiled orientation modification automatically implies a tile orientation
 208         for any other application already present/active at that time.
 209
 210         In case there's already a client active at that time, it will be
 211         attributed automatically the opposite tiled orientation, such that two
 212         concurrent applications can be displayed at the same time.
 213
 214         The orientation tiles can not be combined, and only state at a time
 215         can be active. Only horizontal and vertical tiling is possible. A
 216         horizontal and vertical tile orientation simultaneously is not
 217         possible.
 218
 219         Input focus is being delivered to the last started/activated window,
 220         such that users can cycle between that one or the other, assumes there's
 221         another window in the first place.
 222
 223         See xdg_toplevel.set_app_id from the xdg-shell protocol for a
 224         description of app_id.
 225       </description>
 226       <arg name="app_id" type="string"/>
 227       <arg name="orientation" type="uint" enum="tile_orientation"/>
 228       <arg name="output" type="object" interface="wl_output"/>
 229     </request>
 230
 231   </interface>
 232 </protocol>