compositor: Use stdint for specifing integer storage
[src/agl-compositor.git] / protocol / agl-shell.xml
index 59548e7..f392691 100644 (file)
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <protocol name="agl_shell">
   <copyright>
-    Copyright © 2019 Collabora, Ltd.
+    Copyright © 2019, 2022 Collabora, Ltd.
 
     Permission is hereby granted, free of charge, to any person obtaining a
     copy of this software and associated documentation files (the "Software"),
     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
     DEALINGS IN THE SOFTWARE.
   </copyright>
-  <interface name="agl_shell" version="1">
-    <description summary="user interface for weston-ivi">
+  <interface name="agl_shell" version="11">
+    <description summary="user interface for Automotive Grade Linux platform">
+      Starting with version 2 of the protocol, the client is required to wait
+      for the 'bound_ok' or 'bound_fail' events in order to proceed further.
+
+      In case the client gets a 'bound_fail' event then it should consider that
+      there's another client already bound to the agl_shell protocol.
+      A client that receives a 'bound_ok' event should consider that there's
+      no other client already bound to the interface and can proceed further.
+
+      If the client uses an older version of the protocol it will receive
+      automatically an error and the compositor will terminate the connection,
+      if there's another client already bound the interface.
+
+      If the client receives the 'bound_fail' event and attempts to use the
+      interface further it will receive an error and the compositor will
+      terminate the connection. After the 'bound_fail' event was received the
+      client should call the destructor, which has been added with version 2
+      of the protocol. The client is free to try at a later point in time to
+      see if it will receive the 'bound_ok' event, but there's no explicit way
+      of finding out when that event will be delivered.
+      It is assumed that it can infer that information through other
+      means/other channels.
     </description>
 
     <enum name="error">
       <entry name="right" value="3"/>
     </enum>
 
+    <enum name="app_state" since="3">
+      <entry name="started" value="0"/>
+      <entry name="terminated" value="1"/>
+      <entry name="activated" value="2"/>
+      <entry name="deactivated" value="3"/>
+    </enum>
+
+    <enum name="tile_orientation" since="11">
+      <entry name="none" value="0"/>
+      <entry name="left" value="1"/>
+      <entry name="right" value="2"/>
+      <entry name="top" value="3"/>
+      <entry name="bottom" value="4"/>
+    </enum>
+
     <request name="ready">
       <description summary="client is ready to be shown">
         Tell the server that this client is ready to be shown. The server
         will delay presentation during start-up until all shell clients are
         ready to be shown, and will display a black screen instead.
-        This gives the client an oppurtunity to set up and configure several
+        This gives the client an opportunity to set up and configure several
         surfaces into a coherent interface.
 
         The client that binds to this interface must send this request, otherwise
         Set the surface to act as a panel of an output. The 'edge' argument
         says what edge of the output the surface will be anchored to.
         After this request, the server will send a configure event with the
-        correponding width/height that the client should use, and 0 for the
+        corresponding width/height that the client should use, and 0 for the
         other dimension. E.g. if the edge is 'top', the width will be the
         output's width, and the height will be 0.
 
       <arg name="output" type="object" interface="wl_output"/>
       <arg name="edge" type="uint" enum="edge"/>
     </request>
+
+    <request name="activate_app">
+      <description summary="make client current window">
+        Ask the compositor to make a toplevel to become the current/focused
+        window for window management purposes.
+
+        See xdg_toplevel.set_app_id from the xdg-shell protocol for a
+        description of app_id.
+
+        If multiple toplevels have the same app_id, the result is unspecified.
+
+        XXX: Do we need feedback to say it didn't work? (e.g. client does
+        not exist)
+      </description>
+      <arg name="app_id" type="string"/>
+      <arg name="output" type="object" interface="wl_output"/>
+    </request>
+
+    <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 with a split orientation">
+        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.
+
+        A width size can also be specified for the split window. Note that this
+        width can't exceed the output width value, or the compositor can choose
+        to ignore this value.
+
+        Making the split window sticky would inform the compositor that the
+        window should always be active when switching or when activating between
+        other windows. This would allow navigating, starting and activating other
+        windows while keeping the current window always in a split state.
+
+        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="width" type="int" summary="width of the window being split"/>
+      <arg name="sticky" type="int" summary="make the split window stiky"/>
+      <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>
   </interface>
 </protocol>