1_agl-compositor: Mention agl-shell-app-id for migrating apps 36/26136/2
authorMarius Vlad <marius.vlad@collabora.com>
Thu, 4 Mar 2021 12:35:19 +0000 (14:35 +0200)
committerJan-Simon Moeller <jsmoeller@linuxfoundation.org>
Mon, 15 Mar 2021 22:49:23 +0000 (22:49 +0000)
Besides using the agl-shell-desktop protocol one can use agl-shell-app-id
to migrate surfaces to other local, or remote outputs.

Bug-AGL: SPEC-3820

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Change-Id: Ifdb5853a9a3eaf9dc041d68596c353548437c64b
Reviewed-on: https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/26136
Tested-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
Reviewed-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
docs/5_Component_Documentation/1_agl-compositor.md

index 666a2fa..e4e69f0 100644 (file)
@@ -192,6 +192,12 @@ implemented by the client, for instance [xdg-output](https://gitlab.freedesktop.
 is the one recommended way and provides a mapping between a human
 representation of the output and the wayland one.
 
 is the one recommended way and provides a mapping between a human
 representation of the output and the wayland one.
 
+One can also choose the output where the application can start, by configuring
+directly the AGL compositor. Under the `[output]` section one can use
+`agl-shell-app-id=appid` restart the AGL compositor unitd systemd service and
+start the application. Currently this *only* applies to regular applications, the
+client shell having to handle it in the code.
+
 ## Available toolkits, application conversions and available eco-systems
 
 Users and OEM vendors alike have the possibility, depending on their use-cases,
 ## Available toolkits, application conversions and available eco-systems
 
 Users and OEM vendors alike have the possibility, depending on their use-cases,
@@ -239,6 +245,11 @@ capable of loading up libweston modules and make use of them. And just like
 weston, the AGL compositor loads up the remoting-plugin to achieve the same
 thing.
 
 weston, the AGL compositor loads up the remoting-plugin to achieve the same
 thing.
 
+The remoting-plugin uses the DRM virtual output API from libweston together
+with gstreamer pipeline to capture, using DMA buffers, the DRM output and to
+stream it, remotely to another machine. They can be over the network, or
+locally.
+
 Further more, to cope with situations where the output is just a
 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
 Further more, to cope with situations where the output is just a
 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