X-Git-Url: https://gerrit.automotivelinux.org/gerrit/gitweb?a=blobdiff_plain;f=doc%2FApplicationGuide.md;h=2240bb1161ab30adf5f5748cc38a3f0c0ad70347;hb=refs%2Fchanges%2F61%2F15461%2F2;hp=25d87be52f11ec007457166bfbbaf1ba39fb3f7b;hpb=074d058a7a483a66af7f8c0b928b321ad483f47c;p=apps%2Fagl-service-windowmanager-2017.git
diff --git a/doc/ApplicationGuide.md b/doc/ApplicationGuide.md
index 25d87be..2240bb1 100644
--- a/doc/ApplicationGuide.md
+++ b/doc/ApplicationGuide.md
@@ -1,23 +1,58 @@
**Window Manager Application Guide**
====
-
Revision: 0.2Beta
+Revision: 0.5
TOYOTA MOTOR CORPORATION
-30th/Sep/2017
+20th/Mar/2018
* * *
+
+
+Table of content
+============
+- [Introduction](#Introduction)
+ - [Intended audience](#Intended\ audience)
+ - [Scope of this Document](#Scope\ of\ this\ Document)
+ - [Known Issues](#Known\ Issues)
+ - [External libraries](#External\ libraries)
+ - [Client Library](#Client\ Library)
+- [Concepts](#Concepts)
+ - [Layers](#Layers)
+ - [Surfaces](#Surfaces)
+- [Configuration](#Configuration)
+ - [Configuration Items](#Configuration\ Items)
+- [Building and Running](#Building\ and\ Running)
+ - [Dependencies](#Dependencies)
+ - [Build Configuration](#Build\ Configuration)
+- [Implementation Notes](#Implementation\ Notes)
+ - [Structure](#Structure)
+- [Sequence](#Sequence)
+- [Binding API](#Binding\ API)
+ - [LibWindowmanager](#LibWindowmanager)
+ - [Methods](#Methods)
+ - [Errors](#Errors)
+ - [Usage](#Usage)
+ - [Events](#Events)
+- [Sample](#Sample)
+
+
+
Introduction
============
-This WindowManager implements simple layout switching of applications on
+This window manager implements simple layout switching of applications on
multiple layers and with different layer layouts.
+
+
Intended audience
-----------------
-This documentation is intended for developers and system integrators who
+This document is intended for developers and system integrators who
need to know, how the window manager works and how it is to be used.
+
+
Scope of this Document
----------------------
@@ -27,16 +62,18 @@ implementation details, concepts of operation, configuration and usage.
It does not include
-- documentation of the underlying architecture, see
+- document of the underlying architecture, see
[HMI-Framework](https://wiki.automotivelinux.org/hmiframework).
-- documentation of the AGL application framework and its technologies,
+- document of the AGL application framework and its technologies,
see [AGL Application
Framework](https://wiki.automotivelinux.org/agl-distro/app-framework).
It is highly recommended to have a good understanding of these documents
and projects before using the window manager.
+
+
Known Issues
------------
@@ -46,20 +83,23 @@ Currently there is a one known issues:
libwindowmanager library. This is a limitation of how Qt creates surface
IDs for the ivi-application interface.
+
+
External libraries
------------------
This project includes a copy of version 2.1.1 the excellent [C++11 JSON
library by Niels Lohmann](https://github.com/nlohmann/json).
+
+
Client Library
--------------
A client library implementation that internally uses the *libafbwsc*, is
-provided in the subdirectory `libwindowmanager/` with its own documentation
-directory.
+provided in the `libwindowmanager`.
-The client library is built together with the window manager itself.
+
Concepts
========
@@ -67,6 +107,8 @@ Concepts
The window manager implements a couple of concepts in order to allow
efficient implementation.
+
+
Layers
------
@@ -85,122 +127,32 @@ currently used layer.
It is possible to deactivate these surfaces on lower layers explicitly
using the `DeactivateSurface` API call.
+
+
Surfaces
--------
Surfaces are *placed* on layers according to their name. The surface
-will then be resized to dimensions, according to the layerâs layout
+will then be resized to dimensions, according to the layer's layout
configuration.
-Binding API
-===========
-
-The binding API consists of a couple of AFB *verbs* - that is; function
-calls to the Window Manager.
-
-Verbs (Functions)
------------------
-
-Each function returns a reply containing at least a failed or successful
-result of the call, additionally, when calls return something, it is
-noted. The notation used has the following meaning:
-
- FunctionName(argument_name: argument_type)[: function_return_type]
-
-Where the return type may be omitted if it is void.
-
-- `RequestSurface(drawing_name: string): int` Request a surface ID for
- the given name. This name and ID association will live until the
- surface is destroyed (or e.g. the application exits). Each surface
- that is managed by the window manager needs to call this function
- first!
-
-- `ActivateSurface(drawing_name: string)` This function requests the
- activation of a surface. It usually is not called by the
- application, but rather by the application framework or
- the HomeScreen.
-
-- `DeactivateSurface(drawing_name: string)` Request deactivation of
- a surface. This function is not usually called by applications
- themselves, but rather by the application framework or
- the HomeScreen.
-
-- `EndDraw(drawing_name: string)` Signals the window manager, that the
- surface is finished drawing. This is useful for consistent
- flicker-free layout switches, see the Architecture document
- for details.
-
-There are a couple of non-essential (mostly for debugging and
-development) API calls:
-
-- `list_drawing_names(): json` List known surface *name* to
- *ID* associations.
-
-- `ping()` Ping the window manager. Does also dispatch pending events
- if any.
-
-- `debug_status(): json` Returns a json representation of the current
- layers and surfaces known to the window manager. This represents the
- wayland-ivi-extension objectâs properties.
-
-- `debug_surfaces(): json` Returns a json representation of all
- surfaces known to the window manager. This represents the
- wayland-ivi-extension properties of the surfaces.
-
-- `debug_layers(): json` Returns the current layer configuration, as
- configured through *layers.json*.
-
-- `debug_terminate()` Terminates the afb-daemon running the window
- manager binding, if the environment variable
- `WINMAN_DEBUG_TERMINATE` is set.
-
-Events
-------
-
-The window manager broadcasts certain events (to all applications) that
-signal information on the state of the surface regarding the current
-layout.
-
-- `Active(drawing_name: string)` Signal that the surface with the name
- `drawing_name` is now active.
-
-- `Inactive(drawing_name: string)` Signal that the surface with the
- name `drawing_name` is now inactive. This usually means, the layout
- got changed, and the surface is now considered inactive
- (or sleeping).
-
-- `Visible(drawing_name: string)` Signal applications, that the
- surface with name `drawing_name` is now visible.
-
-- `Invisible(drawing_name: string)` Signal applications that the
- surface with name `drawing_name` is now invisible.
-
-- `SyncDraw(drawing_name: string)` Signal applications, that the
- surface with name `drawing_name` needs to redraw its content - this
- usually is sent when the surface geometry changed.
-
-- `FlushDraw(drawing_name: string)` Signal to applications, that the
- surface with name `drawing_name` can now be swapped to its newly
- drawn content as the window manager is ready to activate a new
- layout (i.e. a new surface geometry).
-
-Binding API Usage
------------------
-For a detailed description on how the binding API is supposed to be
-used, refer to the Architecture document.
+
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 window manager will use default configuration unless this configuration is found.
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.
+
+Note:
+Currently, window manager doesn't block the application displaying because "Fallback" is set by default. If the "Fallback" is not set in layers.json, window manager blocks the application displaying. In such a situation, you have to add your role(application name) at "role" in layers.json.
+
+
Configuration Items
-------------------
@@ -231,30 +183,43 @@ This configuration item is a list of surface-name to layer mappings.
#### surface to layer mapping
"mappings": [
- {
- "role": "^HomeScreen$",
- "name": "HomeScreen",
- "layer_id": 1000,
- "area": { "type": "full" },
- },
- {
- "role": "MediaPlayer|Radio|Phone",
- "name": "apps",
- "layer_id": 1001,
- "area": { "type": "rect",
- "rect": { "x": 0,
- "y": 100,
- "width": -1,
- "height": -201 } },
- "split_layouts": []
- }
+ {
+ "role": "^HomeScreen$",
+ "name": "HomeScreen",
+ "layer_id": 1000,
+ "area": { "type": "full" },
+ "comment": "Single layer map for the HomeScreen"
+ },
+ {
+ "role": "MediaPlayer|Radio|Phone|Navigation|HVAC|Settings|Dashboard|POI|Mixer",
+ "name": "apps",
+ "layer_id": 1001,
+ "area": { "type": "rect", "rect": { "x": 0, "y": 218, "width": -1, "height": -433 } },
+ "comment": "Range of IDs that will always be placed on layer 1001, negative rect values are interpreted as output_size.dimension - $value",
+
+ "split_layouts": [
+ {
+ "name": "Navigation",
+ "main_match": "Navigation",
+ "sub_match": "HVAC|MediaPlayer",
+ "priority": 1000
+ }
+ ]
+ },
+ {
+ "role": "^OnScreen.*",
+ "name": "popups",
+ "layer_id": 9999,
+ "area": { "type": "rect", "rect": { "x": 0, "y": 760, "width": -1, "height": 400 } },
+ "comment": "Range of IDs that will always be placed on the popup layer, that gets a very high 'dummy' id of 9999"
+ }
]
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
@@ -275,7 +240,7 @@ layer, this is mostly useful for the main\_surface or HomeScreen layer.
coordinates `x` and `y` as well as its dimensions `width` and `height`.
The dimensions can be specified relative to the screen dimensions. For
-this negative values for width and height mus be used.
+this negative values for width and height must be used.
For example, a full-screen surface can have the following `rect`
definition:
@@ -317,9 +282,9 @@ activated).
"split_layouts": [
{
- "name": "Media Player",
- "main_match": "^App MPlayer Main$",
- "sub_match": "^App MPlayer Sub",
+ "name": "Navigation",
+ "main_match": "Navigation",
+ "sub_match": "HVAC|MediaPlayer",
}
]
@@ -335,20 +300,22 @@ 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!
+The names must still match the layer's role match!
+
+
Building and Running
====================
+
+
Dependencies
------------
-This project is intended to be build with the 4.0 release of AGL.
-
Build dependencies are as follows:
- afb-daemon >= 1.0
@@ -357,45 +324,51 @@ Build dependencies are as follows:
- wayland-client >= 1.11
-- cmake >= 3.6.1
+- wayland-ivi-extension >= 2.0.2 (until eel, wayland-ivi-extension >= 1.13)
+
+- cmake >= 2.8
+
+
+
+Supported environment
+-------------------
+
+| Item | Description |
+|:------------|:----------------------------------|
+| AGL version | Electric Eel |
+| Hardware | Renesas R-Car Starter Kit Pro(M3) |
+
+
+
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
+$ source meta-agl/scripts/aglsetup.sh -m m3ulcb agl-demo
+$ 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.
-
+
Implementation Notes
====================
@@ -404,42 +377,7 @@ The window manager is implemented as a app-framework-binder binding.
That means, the build produces one shared object that exports a binding
interface.
-Binding code generation
------------------------
-
-The binding API is rather simple; functions receive a json object
-describing arguments and return a json object describing the result or
-an error. In order to simplify development, the
-`generate-binding-glue.py` script was added, that contains a description
-of the API as a python dictionary. This script generates the header
-`afb_binding_api.hpp` and the afb binding functions as
-`afb_binding_glue.inl`. Where the latter is included in `main.cpp`.
-
-Each function for the AFB binding that is generated does the following:
-
-- Lock the binding mutex, so that we serialize all access to
- the binding.
-
-- Do some debug logging (if wanted).
-
-- Check the binding state, i.e. the compositor might have exited
- unexpectedly at which point it would not make sense to continue.
-
-- Extract the arguments from the json object that is provided (doing
- some primitive type checking).
-
-- Call the afb\_binding\_api method corresponding to this binding
- function
-
-- Check the afb\_binding\_apiâs function return value, log an error
- state and return the result to the afb request.
-
-The generated functions do also check for any "loose" exception that
-comes out of the afb\_binding\_api call (which in turn might call the
-actual non-trivial implementation in `App`). However, **IF** an
-exception is thrown and not handled inside the afb\_binding\_call, that
-internal state of the window manager might be broken at this time (hence
-the talkative error log).
+
Structure
---------
@@ -447,25 +385,20 @@ Structure
The implementation is loosely split across the following source files:
- `main.cpp`: The program entry point as used by the afb-daemon. This
- file defines the afbBindingV2 symbol tat is used by the afb-daemon
+ file defines the afbBindingV2 symbol that is used by the afb-daemon
in order to load a binding. It also defines the wayland fd event
dispatcher and some globals to be used (as context for the afb calls
we receive).
-- `afb_binding_api.cpp`: The implementation of the afb
- binding functions. The actual functions are generated by
- `generate-binding-glue.py` which generates a **.inl** file that is
- included by `main.cpp`.
-
-- `app.cpp` / `app.hpp`: This is the main application
+- `app.cpp` / `app.hpp`: This is the main window manager
logic implementation.
- `config.cpp` / `config.hpp`: Very simple configuration
item interface.
- `controller_hooks.hpp`: hook functions called by the wayland
- controller to call into the App instance. Only a very limited number
- of events are passed to the Application, which allowed the usage of
+ controller to call into the window manager instance. Only a very limited number
+ of events are passed to the window manager, which allowed the usage of
such a simple interface.
- `json_helper.cpp` / `json_helper.hpp`: Smaller json related
@@ -473,7 +406,7 @@ The implementation is loosely split across the following source files:
- `layers.cpp` / `layers.hpp`: Actually hold all the data from
layers.json configuration, do some transformations and service the
- App implementation.
+ window manager implementation.
- `layout.cpp` / `layout.hpp`: Very simple layout state for the
implementation of split layouts and tracking of the
@@ -490,8 +423,335 @@ The implementation is loosely split across the following source files:
- `util.cpp` / `util.hpp`: general utility functions and structs - and
preprocessor definitions (e.g. `log*()` to AFB logging functions.
-- `wayland.cpp` / `wayland.hpp`: A C++ object-oriented
+- `wayland_ivi_wm.cpp` / `wayland_ivi_wm.hpp`: A C++ object-oriented
libwayland-client wrapper. It is instanced in `main.cpp` and handles
- all our wayland needs.
+ all our wayland needs. These files are in master. In eel, the name
+ of these files are `wayland.cpp` / `wayland.hpp`
+
+
+
+Sequence
+===============
+
+To understand the sequence between application and window manager, refer to the [spec document](https://wiki.automotivelinux.org/windowmanager).
+
+
+
+
+Binding API
+===============
+
+Each function returns a reply containing at least a failed or successful
+result of the call, additionally, when calls return something, it is
+noted.
+
+
+
+LibWindowmanager
+------
+
+This is the public interface of the class `LibWindowmanager`.
+
+ class LibWindowmanager
+ {
+ public:
+ LibWindowmanager();
+ ~LibWindowmanager();
+
+ enum EventType {
+ Event_Active = 0,
+ Event_Inactive,
+
+ Event_Visible,
+ Event_Invisible,
+
+ Event_SyncDraw,
+ Event_FlushDraw,
+ };
+
+ int init(int port, char const *token);
+
+ // Window manager API
+ int requestSurface(json_object *object);
+ int requestSurfaceXDG(json_object *object);
+ 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);
+
+ };
+
+
+
+Methods
+-------
+
+### init(int port, char const *token)
+
+Initialize the Binding communication.
+
+The `token` parameter is a string consisting of only alphanumeric characters.
+If these conditions are not met, the LibWindowmanager instance will not initialize,
+i.e. this call will return `-EINVAL`.
+
+The `port` parameter is the port the afb daemon is listening on, an
+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 `surface id` a client application can use, and
+`-errno` on failure. Additionally, on the standard error, messages are
+logged to help debugging the issue.
+
+### requestSurfaceXDG(json_object *object)
+
+**args: `{ 'kKeyDrawingName': 'application name', 'kKeyIviId': 'ivi id' }`**
+This method is mainly intended for *xdglauncher* that controls xdg application such as chromium.
+It will return `surface id` xdglauncher uses, and
+`-errno` on failure. Additionally, on the standard error, messages are
+logged to help debugging the issue.
+
+### activateSurface(json_object *object)
+
+**args: `{ 'kKeyDrawingName': 'application name', 'kKeyDrawingArea': 'layout' }`**
+This method is mainly intended for *manager* applications that control
+other applications (think an application manager or the *HomeScreen*).
+It instructs the window manager to activate the surface with the given
+*label*.
+
+This method only is effective after the actual window or surface was
+created by the application.
+
+### deactivateSurface(json_object *object)
+
+**args: `{ 'kKeyDrawingName': 'application name' }`**
+This method is mainly intended for *manager* applications that control other applications.
+In adition, this is for applications that overrides other applications such like popup message.
+In this case, popup surface requests to be hidden. It instructs the window manager to deactivate the surface associated with the given label. Note, that deactivating a surface also means to implicitly activate another (the last active or if not available *main surface* or *HomeScreen*.)
+
+This method only is effective after the actual window or surface was
+created by the application.
+
+### endDraw(json_object *object)
+
+**args: `{ 'kKeyDrawingName': 'application name' }`**
+This function is called from a client application when it is done
+drawing its surface content.
+
+It is not crucial to make this call at every time a drawing is finished
+- it is mainly intended to allow the window manager to synchronize
+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
+events described in the EventType enum. Only one hendler for each
+EventType is possible, i.e. if it is called multiple times with the same
+EventType the previous handler will be replaced.
+
+The `func` handler functions will receive the label of the surface this
+event is targeted at.
+
+See Section [Events](#_events) for more detailed information about event
+delivery to client applications.
+
+
+
+Errors
+------
+
+Methods returning an `int` signal successful operation when returning
+`0`. In case of an error, an error value is returned as a negative errno
+value. E.g. `-EINVAL` to signal that some input value was invalid.
+
+Additionally, logging of error messages is done on the standard error
+file descriptor to help debugging the issue.
+
+
+
+Usage
+-----
+
+### Initialization of LibWindowmanager
+
+Before usage of the LibWindowmanager, the method `init()` must be
+called once, it will return `-errno` in case of an error and log
+diagnostic messages to stderr.
+
+### Request a surface
+
+When creating a surface with *Qt* - it is necessary to request a surface
+from the WM, internally this will communicate with the window manager
+binding. Only after `requestSurface()` was successful, a surface should
+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 `surface id` a client application can use
+after the surface was requested successfully.
+
+#### Workings of requestSurface()
+
+`LibWindowmanager::requestSurface()` calls the AFB binding verb
+`requestsurface` of the `windowmanager` API. This API call will return a
+numeric ID to be used when creating the surface. This ID is never
+explicitly returned to the client application, instead, it is set in the
+application environment in order for *Qt* to then use it when creating
+the surface.
+
+With the current *Qt* implementation this means, that only one surface
+will be available to client applications, as subsequent windows will
+increment this numeric ID internally - which then will lead to IDs that
+cannot be known by the window manager as there is no direct
+communication from *Qt* to the WM.
+
+
+
+Events
+------
+
+Events are a way for the *Window Manager* to propagate information to
+client applications. It was vital for the project to implement a number
+of events, that mirror functionality that is already present in the
+wayland protocol.
+
+All events have the surface label as argument - a way to enable future
+multi-surface applications.
+
+As already stated above, this is currently not possible with the way
+*Qt* implements its surface ID setting.
+
+### Active and Inactive Events
+
+These events signal an application that it was activated or deactivated
+respectively. Usually this means it was switched visible - which means
+the surface will now be on the screen and therefor continue to render.
+
+- `Active(json_object *object)`
+ args: { 'kKeyDrawingName': 'application name' }
+ Signal that the surface with the name
+ `kKeyDrawingName` is now active.
+
+- `Inactive(json_object *object)`
+ args: { 'kKeyDrawingName': 'application name' }
+ Signal that the surface with the
+ name `kKeyDrawingName` is now inactive. This usually means, the layout
+ got changed, and the surface is now considered inactive
+ (or sleeping).
+
+### Visible and Invisible
+
+These events signal an application that it was switched to be visible or
+invisible respectively. These events also are handled implicitly through
+the wayland protocol by means of `wl_surface::enter` and
+`wl_surface::leave` events to the client.
+
+- `Visible(json_object *object)`
+ args: { 'kKeyDrawingName': 'application name' }
+ Signal applications, that the
+ surface with name `kKeyDrawingName` is now visible.
+
+- `Invisible(json_object *object)`
+ args: { 'kKeyDrawingName': 'application name' }
+ Signal applications that the
+ surface with name `kKeyDrawingName` is now invisible.
+
+### SyncDraw and FlushDraw
+
+These events instruct applications that they should redraw their surface
+contents - again, this is handled implicitly by the wayland protocol.
+
+`SyncDraw` is sent to the application when it has to redraw its surface.
+
+`FlushDraw` is sent to the application when it should swap its buffers,
+that is *signal* the compositor that its surface contains new content.
+
+- `SyncDraw(json_object *object)`
+ 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
+ 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' }
+ Signal applications, that the
+ surface with name `kKeyDrawingArea` can now be swapped to its newly
+ drawn content as the window manager is ready to activate a new
+ layout (i.e. a new surface geometry).
+
+
+
+Sample
+============
+
+In order to enable application to use the `WM` surface registration
+function the above described steps need to be implemented.
+
+As a minimal example the usage and initialization can look like the
+following.
+Repo: `apps/agl-service-homescreen-2017`
+Path: `sample/template/main.c`