started, among other things.
Management of applications, starting, running and stopping them is done in AGL
-with AppFW [Application Framework Management](../04_Developer_Guides/01_Application_Framework/01_Introduction.md),
+with AppFW [Application Framework Management](Application_Framework/01_Introduction.md),
which is an umbrella name to denote the suite of tools and daemons that handle
all of that. It is integrated with systemd and with the current security model.
Applications can use AppFW to hang off data, and to pass it down to
Further more, with this protocol update we also includes some events already
present in the agl-shell-desktop protocol like deactivate and terminate.
-### agl-shell-desktop
+### agl-shell-desktop (deprecated, will be removed in future, see gRPC proxy)
This extension is targeted at keeping some of the functionally already
established in AGL as to a) allow applications display/activate other
the current activate one, with each output having independently active
surfaces.
+## gRPC proxy for window management
+
+The gRPC proxy is an alternative to allow management of windows,
+without the need for clients to "speak" native Wayland C code. Most major
+languages have RPC bindings, and in AGL clients do not touch Wayland code
+natively, using most of the time toolkits. It seemed reasonably to use gRPC
+as a way to interact with the compositor. The way this works is that
+there's proxy daemon started by the compositor which translates the gRPC
+calls to Wayland ones, using agl-shell protocol. Events coming from the
+compositor are handled by subscribing to RPC stream events, such that
+clients can act upon as well, so it is not just one way interaction.
+
+With respect to window management: placement, movement, and surface role
+changes all should, and can be done with RPC. Some of the calls, specifically
+background set-up or activation area, are still required to happen prior or
+require wayland primitives which can't be passed between processes, so those
+can't be used with RPC proxy.
+
+In terms of API, the following are available: activation/deactivation,
+role management, and events. All the message arguments are self-explanatory,
+requiring always an app_id, in form of string and possibly an output, in
+form a string as well. Toolkits can set/retrieve this information so refer
+to the respective toolkit. At the wayland level, the app_id is set/get
+with [xdg-shell](https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:set_app_id)
+whereas output from [wl_output interface](https://wayland.app/protocols/wayland#wl_output:event:name)
+
+Activation and deactivation of applications:
+
+```
+rpc ActivateApp(ActivateRequest) returns (ActivateResponse) {}
+rpc DeactivateApp(DeactivateRequest) returns (DeactivateResponse) {}
+```
+With the following message arguments:
+
+```
+message ActivateRequest {
+ string app_id = 1;
+ string output_name = 2;
+}
+
+message ActivateResponse {
+};
+
+
+message DeactivateRequest {
+ string app_id = 1;
+};
+
+message DeactivateResponse {
+};
+```
+
+Management of surface roles can be done with these requests:
+
+
+```
+rpc SetAppSplit(SplitRequest) returns (SplitResponse) {}
+rpc SetAppFloat(FloatRequest) returns (FloatResponse) {}
+rpc SetAppFullscreen(FullscreenRequest) returns (FullscreenResponse) {}
+rpc AppStatusState(AppStateRequest) returns (stream AppStateResponse) {}
+rpc GetOutputs(OutputRequest) returns (ListOutputResponse) {}
+rpc SetAppNormal(NormalRequest) returns (NormalResponse) {}
+rpc SetAppOnOutput(AppOnOutputRequest) returns (AppOnOutputResponse) {}
+rpc SetAppPosition(AppPositionRequest) returns (AppPositionResponse) {}
+rpc SetAppScale(AppScaleRequest) returns (AppScaleResponse) {}
+```
+
+Message arguments are:
+
+```
+message SplitRequest {
+ string app_id = 1;
+ int32 tile_orientation = 2;
+ int32 width = 3;
+ int32 sticky = 4;
+ string output_name = 5;
+}
+
+message SplitResponse {
+};
+
+message FloatRequest {
+ string app_id = 1;
+ int32 x_pos = 2;
+ int32 y_pos = 3;
+};
+
+message FloatResponse {
+};
+
+message NormalRequest {
+ string app_id = 1;
+};
+
+message NormalResponse {
+};
+
+message FullscreenRequest {
+ string app_id = 1;
+};
+
+message FullscreenResponse {
+};
+
+message AppOnOutputRequest {
+ string app_id = 1;
+ string output = 2;
+};
+
+message AppOnOutputResponse {
+};
+
+message AppPositionRequest {
+ string app_id = 1;
+ int32 x = 2;
+ int32 y = 3;
+};
+
+message AppPositionResponse {
+};
+
+message AppScaleRequest {
+ string app_id = 1;
+ int32 width = 2;
+ int32 height = 3;
+};
+
+message AppScaleResponse {
+};
+```
+
+Events which clients can subscribe to:
+
+```
+rpc AppStatusState(AppStateRequest) returns (stream AppStateResponse) {}
+```
+
+With the message arguments:
+
+```
+message AppStateRequest {
+};
+
+message AppStateResponse {
+ int32 state = 1;
+ string app_id = 2;
+};
+```
+
+A C++ client implementation the gRPC API can be found in [agl-shell-activator](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/agl-shell-activator.git;a=tree;h=refs/heads/master;hb=refs/heads/master)
+or in [window-management-client-grpc](https://gerrit.automotivelinux.org/gerrit/gitweb?p=src/window-management-client-grpc.git;a=tree;h=refs/heads/master;hb=refs/heads/master).
+
## Explicit output
The activation and setting surface roles requires passing a Wayland output
panel/display, without some kind of compositor driving it, the necessity of
handling input events is an important feature to have, giving the user to
possibility to manipulate the application/environment as he or she seems fit.
+
The compositor loads a plug-in that streams out the buffers to an output
-remotely, with [another plug-in](2_waltham-receiver_waltham-transmitter.md)
-handling the input events. The events, which are sent back from the display to
-the compositor, are generated with the help of wayland-eque protocol that works
-over the network, called [Waltham](https://github.com/waltham/waltham).
+remotely, with another plug-in was used to handle the input events. The events,
+which are sent back from the display to the compositor, are generated with
+the help of wayland-eque protocol that works over the network, called
+[Waltham](https://github.com/waltham/waltham). This solution was deprecated
+and removed a while back, with an alternative in the works to achieve
+the same functionality.
Together, they provide proper means to achieve a seamless integration with
other display devices in the car cabin.
In the works, there's a new policy model, called [Role Based
Arbitration](https://gerrit.automotivelinux.org/gerrit/admin/repos/staging/rba).
-Internally, how it works, should be found at [RBA](3_rba.md).
+Internally, how it works, should be found at [RBA](04_Rule_Based_Arbitrator.md).
While the other two policies are embedded into the compositor, the RBA policy
model is an off the-shell policy. Obviously, vendors and users can hook up
their own policies, just like RBA did. These all work towards satisfying
Code Review / AGL / documentation.git / blobdiff