Add APIs which can get information about the display and the surface area
[apps/agl-service-windowmanager.git] / doc / ApplicationGuide.md
index 23e9283..d66f20b 100644 (file)
@@ -98,10 +98,7 @@ Client Library
 --------------
 
 A client library implementation that internally uses the *libafbwsc*, is
-provided in the subdirectory `libwindowmanager/` with its own documentation
-directory.
-
-The client library is built together with the window manager itself.
+provided in the `libwindowmanager`.
 
 <div id="Concepts"></div>
 
@@ -147,13 +144,11 @@ Configuration
 =============
 
 The window manager is configured with the *layers.json* configuration
-file, by default it is searched in `/etc/layers.json` but through the
-use of the environment variable `LAYERS_JSON` the WM can be instructed
-to use different file. Note, that the WM will not run unless this
-configuration is found and valid.
+file, by default it is searched in `${AFM_APP_INSTALL_DIR}/etc/layers.json`.
+Note, that the WM will not run unless this configuration is found and valid.
 
 A sample configuration is provided with the window manager
-implementation, this sample is installed to /etc/layers.json.
+implementation, this sample is installed to ${AFM_APP_INSTALL_DIR}/etc/layers.json.
 
 <div id="Configuration\ Items"></div>
 
@@ -191,7 +186,7 @@ This configuration item is a list of surface-name to layer mappings.
          "name": "HomeScreen",
          "layer_id": 1000,
          "area": { "type": "full" },
-         "comment": "Single layer map for the HomeScreen, XXX: type is redundant, could also check existence of id/first_id+last_id"
+         "comment": "Single layer map for the HomeScreen"
       },
       {
          "role": "MediaPlayer|Radio|Phone|Navigation|HVAC|Settings|Dashboard|POI|Mixer",
@@ -222,7 +217,7 @@ Each mapping defines the following items to map corresponding surfaces
 to a layer.
 
 -   `role` defines a regular expression that application drawing names
-    are matched against. If applications match tis regular expression,
+    are matched against. If applications match this regular expression,
     the surface will be visible on this layer.
 
 -   `name` is just a name definition for this layer, it has no
@@ -303,8 +298,8 @@ A split layout object has the following attributes:
     surface of this layout.
 
 In the above example only the surface with drawing name
-`App MPlayer Main` will be used as the *main* surface, but all surfaces
-that begin with `App MPlayer Sub` can be used as a *sub* surface for
+`Navigation` will be used as the *main* surface, and the surfaces
+with drawing name `HVAC` or `MediaPlayer` can be used as a *sub* surface for
 this layout.
 
 The names must still match the layer's role match!
@@ -331,6 +326,17 @@ Build dependencies are as follows:
 
 -   cmake &gt;= 3.6.1
 
+<div id="Supported environment"></div>
+
+Supported environment
+-------------------
+
+| Item        | Description                       |
+|:------------|:----------------------------------|
+| AGL version | Electric Eel                      |
+| Hardware    | Renesas R-Car Starter Kit Pro(M3) |
+
+
 <div id="Build\ Configuration"></div>
 
 Build Configuration
@@ -338,39 +344,28 @@ Build Configuration
 
 **Download recipe**
 If repo is already done, please start with git clone
+
 ```
 $ mkdir WORK
 $ cd WORK
-$ repo init -b dab -m dab_4.0.0_xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
+$ repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
 $ repo sync
-$ git clone https://gerrit.automotivelinux.org/gerrit/staging/meta-hmi-framework
 
 ```
 
 Then you can get the following recipe.
-* `meta-hmi-framework/windowmanager`
 
+* `meta-agl-devel/meta-hmi-framework/recipes-graphics/agl-service-windowmanager-2017`
+
+* `meta-agl-devel/meta-hmi-framework/recipes-graphics/libwindowmanager`
 
 **Bitbake**
+
 ```
 $ source meta-agl/scripts/aglsetup.sh -m m3ulcb agl-demo agl-devel agl-appfw-smack agl-hmi-framework
-$ bitbake agl-service-windowmanager-2017
+$ bitbake agl-demo-platform
 ```
 
-
-A couple of build options to configure the build are available:
-
--   `ENABLE_DEBUG_OUTPUT:BOOL` Compiles including very verbose debug
-    output from the window manager, use --verbose three times on an
-    afb-daemon instance to see the debug messages.
-
--   `ENABLE_SCOPE_TRACING:BOOL` Enables a simple scope tracing mechanism
-    used for a rather small portion of the window manager code. However,
-    it is used quite extensively in the libwindowmanager implementation.
-
-By default these options will be disabled.
-
-
 <div id="Implementation\ Notes"></div>
 
 Implementation Notes
@@ -522,6 +517,10 @@ This is the public interface of the class `LibWindowmanager`.
         int activateSurface(json_object *object);
         int deactivateSurface(json_object *object);
         int endDraw(json_object *object);
+        int getDisplayInfo(json_object *object);
+        int getAreaInfo(json_object *in_obj, json_object *out_obj);
+
+        int getAreaInfo(const char *label, json_object *out_obj);
 
         void set_event_handler(enum EventType et, handler_fun f);
 
@@ -546,8 +545,8 @@ invalid port will lead to a failure of the call and return `-EINVAL`.
 ### requestSurface(json_object *object)
 
 **args: `{ 'kKeyDrawingName': 'application name' }`**  
-This method requests a surface with the label given from the *Window
-Manager*. It will return `0` for a successful surface request, and
+This method requests a surface with the label given from the *Window Manager*.
+It will return `surface id` a client application can use, and
 `-errno` on failure. Additionally, on the standard error, messages are
 logged to help debgging the issue.
 
@@ -585,6 +584,56 @@ It is not crucial to make this call at every time a drawing is finished
 drawing in case of layout switch. The exact semantics are explained in
 the next [Events](#_events) Section.
 
+### getDisplayInfo(json_object *object)
+
+**args: `{ }`**  
+This function gets the display information as follows:
+ - width[pixel]
+ - height[pixel]
+ - width[mm]
+ - height[mm]
+
+It outputs the display information for json_object in the argument as follows:  
+  `{"width_pixel": int value of width[pixel], "height_pixel": int value of height[pixel],
+    "width_mm": int value of width[mm], "height_mm": int value of height[mm]}`
+
+It should be called after calling init().
+It should not be called in the event handler because it occurs hang-up.
+
+#### NOTE
+It uses wl_output::geometry() for getting physical width[mm] and height[mm] of the display,
+but the value is different with measured value.
+
+ - value from wl_output::geometry(): width:320 height:520
+ - measured value                  : width:193 height:343
+
+### getAreaInfo(json_object *in_obj, json_object *out_obj)
+
+**args1: `{ 'kKeyDrawingName': 'application name' }`**  
+**args2: `{ }`**  
+This function gets the information of area drawn by the application as follows:
+ - x-coordinate
+ - y-coordinate
+ - width
+ - height
+
+It outputs the area information for json_object in the 2nd argument as follows:  
+  `{"x": int value of x-coordinate, "y": int value of y-coordinate,
+    "width": int value of width, "height": int value of height}`
+
+It should be called after calling activateSurface().
+It should not be called in the event handler because it occurs hang-up.
+
+#### NOTE
+The same information can given by SyncDraw event.
+
+### getAreaInfo(const char *label, json_object *out_obj)
+
+**args1: String of application name**  
+**args2: `{ }`**  
+This function is same with `getAreaInfo(json_object *in_obj, json_object *out_obj)`,
+but only has difference of 1st argument.
+
 ### set\_event\_handler(enum EventType et, handler_fun f)
 
 This method needs to be used to register event handlers for the WM
@@ -630,7 +679,8 @@ be created.
 
 This is also true for *QML* applications, where only after the
 `requestSurface()` should the load of the resource be done. The method
-returns `0` after the surface was requested successfully.
+returns `surface id` a client application can use
+after the surface was requested successfully.
 
 #### Workings of requestSurface()
 
@@ -709,10 +759,14 @@ contents - again, this is handled implicitly by the wayland protocol.
 that is *signal* the compositor that its surface contains new content.
 
 -   `SyncDraw(json_object *object)`  
-    args: { 'kKeyDrawingName': 'application name', 'kKeyDrawingArea': 'layout'  }  
+    args: { 'kKeyDrawingName': 'application name', 'kKeyDrawingArea': 'layout',
+            'kKeyDrawingRect': { "x": int value of x-coordinate, "y": int value of y-coordinate,
+                                 "width": int value of width, "height": int value of height } }  
     Signal applications, that the
-    surface with name `kKeyDrawingArea` needs to redraw its content - this
+    surface with name `kKeyDrawingArea` needs to redraw its content
+    in the layout with name `kKeyDrawingArea` - this
     usually is sent when the surface geometry changed.
+    And the area position and size are included with name `kKeyDrawingRect`.
 
 -   `FlushDraw(json_object *object)`  
     args: { 'kKeyDrawingName': 'application name' }