diff options
| -rw-r--r-- | docs/5_Component_Documentation/1_agl-compositor.md | 11 |
1 files changed, 11 insertions, 0 deletions
diff --git a/docs/5_Component_Documentation/1_agl-compositor.md b/docs/5_Component_Documentation/1_agl-compositor.md index 666a2fa..e4e69f0 100644 --- a/docs/5_Component_Documentation/1_agl-compositor.md +++ b/docs/5_Component_Documentation/1_agl-compositor.md @@ -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. +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, @@ -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. +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 |