+
+ <event name="bound_ok" since="2">
+ <description summary="event sent if binding was ok">
+ Informs the client that it was able to bind the agl_shell
+ interface succesfully. Clients are required to wait for this
+ event before continuing further.
+ </description>
+ </event>
+
+ <event name="bound_fail" since="2">
+ <description summary="event sent if binding was nok">
+ Informs the client that binding to the agl_shell interface was
+ unsuccesfull. Clients are required to wait for this event for
+ continuing further.
+ </description>
+ </event>
+
+ <request name="destroy" type="destructor" since="2">
+ <description summary="destroys the factory object">
+ </description>
+ </request>
+
+ <event name="app_state" since="3">
+ <description summary="event sent when an application suffered state modification">
+ Informs the client that an application has changed its state to another,
+ specified by the app_state enum. Client can use this event to track
+ current application state. For instance to know when the application has
+ started, or when terminated/stopped.
+ </description>
+ <arg name="app_id" type="string"/>
+ <arg name="state" type="uint" enum="app_state"/>
+ </event>
+
+ <request name="set_activate_region" since="4">
+ <description summary="sets a specific region to activate">
+ A hint for the compositor to use a custom area, rather than
+ inferring the activation area. If any panels are used
+ the compositor computes the activation area by subtracting the
+ panels geometry area. If no panels are used then the entire output
+ is being used. This request changes that as to hint the compositor
+ to use the supplied rectangle and ignore any potential panels
+ that might been set-up previously.
+
+ In order for this request to take effect it will need to happen
+ before the 'ready' request in order for the compositor to make use of it.
+ Note that any 'set_panel' request be will not be honored, if this request
+ has been called.
+
+ The x and y coordinates use the top-left corner as the origin. The
+ rectangle area shouldn't exceed the output area, while an area smaller
+ than the output, would basically result in showing up the background
+ surface.
+ </description>
+ <arg name="output" type="object" interface="wl_output"/>
+ <arg name="x" type="int" summary="x position of rectangle"/>
+ <arg name="y" type="int" summary="y position of rectangle"/>
+ <arg name="width" type="int" summary="width of rectangle"/>
+ <arg name="height" type="int" summary="height of rectangle"/>
+ </request>
+
+ <request name="deactivate_app" since="5">
+ <description summary="de-activate/hide window identified by app_id">
+ Ask the compositor to hide the toplevel window for window
+ management purposes. Depending on the window role, this request
+ will either display the previously active window (or the background
+ in case there's no previously active surface) or temporarily (or
+ until a 'activate_app' is called upon) hide the surface.
+
+ All the surfaces are identifiable by using the app_id, and no actions
+ are taken in case the app_id is not/was not present.
+
+ See xdg_toplevel.set_app_id from the xdg-shell protocol for a
+ description of app_id.
+ </description>
+ <arg name="app_id" type="string"/>
+ </request>
+
+ <request name="set_app_float" since="6">
+ <description summary="set the window identified by app_id as float">
+ Makes the application identified by app_id as floating. If the
+ application's window is already mapped, in a maximized, normal state,
+ it would transition to the float state.
+
+ For applications that want to modify their own state, this request
+ must be done before the initial surface commit in order to take effect.
+
+ If the application is already in floating state, this request wouldn't
+ do anything.
+
+ There's no persistence of this request, once the application terminated
+ you'll to issue this request again for that particular app_id.
+
+ The x, and y values would be initial position of the window where the
+ window surface will be placed.
+
+ See xdg_toplevel.set_app_id from the xdg-shell protocol for a
+ description of app_id.
+ </description>
+ <arg name="app_id" type="string"/>
+ <arg name="x" type="int" summary="x position"/>
+ <arg name="y" type="int" summary="y position"/>
+ </request>
+
+ <request name="set_app_normal" since="6">
+ <description summary="set the window identified by app_id as normally started">
+ Returns the application identified by app_id as it was in the normal state.
+ This is useful to come back from other states to the maximized state, the
+ normal state applications are started.
+ </description>
+ <arg name="app_id" type="string"/>
+ </request>
+
+ <request name="set_app_fullscreen" since="7">
+ <description summary="">
+ Makes the application identified by app_id as fullscreen. If the
+ application's window is already mapped, in a maximized, normal state,
+ it would transition to the fullscreen state.
+
+ For applications that want to modify their own state, this request
+ must be done before the initial surface commit in order to take effect.
+
+ If the application is already in fullscreen state, this request wouldn't
+ do anything.
+
+ There's no persistence of this request, once the application terminated
+ you'll to issue this request again for that particular app_id.
+
+ See xdg_toplevel.set_app_id from the xdg-shell protocol for a
+ description of app_id.
+ </description>
+ <arg name="app_id" type="string"/>
+ </request>
+
+ <request name="set_app_output" since="8">
+ <description summary="assign an application to a particular output">
+ this would allow the compositor to place an application on a particular
+ output, if that output is indeed available. this can happen before
+ application is started which would make the application start on that
+ particular output. if the application is already started it would
+ move the application to that output.
+
+ there's no persistence of this request, once the application terminated
+ you'll need to issue this request again for that particular app_id.
+
+ see xdg_toplevel.set_app_id from the xdg-shell protocol for a
+ description of app_id.
+ </description>
+ <arg name="app_id" type="string"/>
+ <arg name="output" type="object" interface="wl_output"/>
+ </request>
+
+ <event name="app_on_output" since="8">
+ <description summary="Event sent as a reponse to set_app_output">
+ Clients can use this event to be notified when an application
+ wants to be displayed on a certain output. This event is sent in
+ response to the set_app_output request.
+
+ See xdg_toplevel.set_app_id from the xdg-shell protocol for a
+ description of app_id.
+ </description>
+ <arg name="app_id" type="string"/>
+ <arg name="output_name" type="string"/>
+ </event>
+
+ <request name="set_app_position" since="9">
+ <description summary="move window to a specific position">
+ Clients can inform the compositor to position a floating type of window
+ at the specific location, pointed by x and y value. If the window is
+ not a floating type, the request will be discarded. Note that
+ positioning doesn't take output into consideration nor does orientation
+ of the outpus. It is expected that the client knows already where the
+ position is localed in global coordonate space. If the window doesn't
+ exist the compositor will ignore the request. For this request to
+ function properly the window would first to be set as floating and then
+ it can be moved using this request.
+
+ see xdg_toplevel.set_app_id from the xdg-shell protocol for a
+ description of app_id.
+ </description>
+ <arg name="app_id" type="string"/>
+ <arg name="x" type="int"/>
+ <arg name="y" type="int"/>
+ </request>
+
+ <request name="set_app_scale" since="10">
+ <description summary="scale window to a specific rectangle">
+ Clients can inform the compositor to scale a floating type of window
+ to the values specified in width and height. If the window is
+ not a floating type, the request will be discarded. If the window
+ doesn't exist the compositor will ignore the request. For this request
+ to function properly the window would first to be set as floating
+ and then it can be moved using this request.
+
+
+ see xdg_toplevel.set_app_id from the xdg-shell protocol for a
+ description of app_id.
+ </description>
+ <arg name="app_id" type="string"/>
+ <arg name="width" type="int"/>
+ <arg name="height" type="int"/>
+ </request>
+
+ <request name="set_app_split" since="11">
+ <description summary="set the application split">
+ This requests asks the compositor to change the application from the
+ original mode (whatever that might be) to a split, tiled orientation
+ mode defined in the tile orientation enum.
+ Clients need to implement resizing (to handle xdg-shell configure
+ events) for this to work correctly.
+
+ This request only handles a single level of tiling for practical
+ reasons: to keep implementation simple and straight forward. The
+ compositor will ignore requests if there are already two windows
+ present. The client can verify this request succeed by checking the
+ xdg-shell configure event and with it, the states sent
+ by the compositor.
+
+ If there's no app_id with the supplied name, the compositor will add
+ the app to a pending list in order to be applied when an application
+ gets started, or if the application sets its application after the
+ initial wl_surface.commit request.
+
+ Applications can use this approach if they want to be started in a
+ tiled orientation position, before creating the xdg-shell toplevel role.
+
+ A none orientation type would make the window go back to the original
+ maximized mode. If two windows are side by side, returning one of them
+ back the original mode would mean the other one will be made hidden
+ and the one doing the request for the none orientation will become
+ the currently active window. A further activation, using activate_app
+ request for the other window would make that one active.
+
+ Closing the window in the tiled orientation state implies that either
+ the background surface will displayed, or in case there was another
+ applications being shown at that time, will make that application be
+ returned to the original, maximized state.
+
+ The tiled orientation could be applied independently of each other,
+ such that a client can transition from one tiled orientation to
+ another. Note that any other window already present would literally
+ take the opposite orientation with the one currently being changed. So
+ tiled orientation modification automatically implies a tile orientation
+ for any other application already present/active at that time.
+
+ In case there's already a client active at that time, it will be
+ attributed automatically the opposite tiled orientation, such that two
+ concurrent applications can be displayed at the same time.
+
+ The orientation tiles can not be combined, and only state at a time
+ can be active. Only horizontal and vertical tiling is possible. A
+ horizontal and vertical tile orientation simultaneously is not
+ possible.
+
+ Input focus is being delivered to the last started/activated window,
+ such that users can cycle between that one or the other, assumes there's
+ another window in the first place.
+
+ See xdg_toplevel.set_app_id from the xdg-shell protocol for a
+ description of app_id.
+ </description>
+ <arg name="app_id" type="string"/>
+ <arg name="orientation" type="uint" enum="tile_orientation"/>
+ <arg name="output" type="object" interface="wl_output"/>
+ </request>
+ </interface>
+
+ <interface name="agl_shell_ext" version="1">
+ <description summary="extended user interface for Automotive Grade Linux platform">
+ This interface allows another client bind to the agl_shell interface,
+ while there's another shell client already present.
+
+ The client should first bind to this interface and then inform the
+ compositor with the 'doas_shell_client' request and it wants to bind to
+ the agl_shell interface. The client is still expected, if using a new
+ version of the agl_shell interface, to wait for the 'bound_ok' and
+ 'bound_fail' events before issueing any other requests/events.
+
+ Note that this interface has its limitations, and the compositor would
+ still refuse the act for 'set_panel' or 'set_background' requests
+ of the agl_shell interface if there's already a client that used them.
+
+ Any other requests or events should be delievered and handled as it would
+ a client bound to the agl_shell interface.
+ </description>
+
+ <enum name="doas_shell_client_status">
+ <entry name="success" value="0"/>
+ <entry name="failed" value="1"/>
+ </enum>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroys the factory object">
+ Call the destructor once you're ready with agl_shell_ext interface.
+ This would reset the state and would make any requests made
+ on the agl_shell interface be terminated. The client would need
+ to bind again the agl_shell_ext and issue a 'doas_shell_client'
+ request.
+ </description>
+ </request>
+
+ <request name="doas_shell_client">
+ <description summary="Informs the compositor it wants to bind to the
+ agl_shell interface">
+ Prior to binding to agl_shell interface, this request would inform
+ the compositor that it wants to gain access the agl_shell interface.
+ The client is expected to wait for 'doas_shell_client_done' event and
+ check for a successful status before going further with binding to
+ the agl_shell interface.
+ </description>
+ </request>
+
+ <event name="doas_done">
+ <description summary="event sent as a reply to doas_shell_client">
+ The client should check the status event to verify that the
+ compositor was able to handle the request.
+ </description>
+ <arg name="status" type="uint" enum="doas_shell_client_status"/>
+ </event>