Ramses and wayland
Ramses renderer can be a wayland subcompositor and wayland client.
in case of wayland client if will push its buffer to the system compositor e.g. Weston and will use wl-shell or ivi-application protocol
in case of wayland subcompositor Ramses-Renderer is able to accept connection from the wayland clients but only if they will use ivi-application protocol.
Questions to Ramses framework:
- How Ramses-Renderer is rendering the scene?
- is some protocol available to define which application is visible or not? it the Ramses-Renderer is also the window manager in the system?
Violin Yanev: The renderer can be (and has to be!) controlled by using its API to subscribe, map and render scenes to the available display(s) (think of wl_display, not necessarily a physical display). This API allows to set the state of the scene - should it be uploaded to the GPU, should it be rendered, etc. A scene can have arbitrary content - anything that can be done with OpenGL.
The control of the composition and the "window management" is left to the RAMSES user - the one using the RAMSES library to build an application/compositor/window-manager. It is just a set of tools, nothing more. For example, it is possible to do this:
- Instantiate a renderer and tell it it to open a fullscreen display, connected to the system compositor over wl_shell
- Create a scene with two Quads - one shown on the left, and one on the right side of the screen
- Tell the scene to map ivi-applications with ivi-id = 1 to the left side, and ivi-id = 2 to the right side
- Tell the renderer to show the scene, and listen to incoming wayland connections
- Whenever either ivi-id1 or ivi-id2 connect to the renderer, start an animation to fade them into the screen (i.e. control the shader rendering the quad to set its opacity)
That's just one example - it is possible to implement any kind of compositor with RAMSES. However, RAMSES doesn't have a "control interface" to control the scene - the scene itself is such control mechanism, and it is possible to do considerably more with a 3D OpenGL scene than with a fixed set of control API (that's the reason why BMW decided to move away from the ivi-controller protocol and use 3D scenes instead of a window manager). RAMSES still supports the ivi-control protocol, to control the system compositor, not its own sub-composited scene.
Questions to Wayland Ivi Extension:
Violin Yanev: What is the specified behavior of ivi-control when there are two participants who try to set the state of the compositor?
Eugen Friedrich: Last wins! Currently it is a bit worse any of the ilm_commit calls will trigger the current pending states to be applied, so there is not queue per client. Also we don't think we will improve this for two reasons:
- There should be only one ilm controller in the system or they should be synchronized!
- We are thinking of protecting some of the wayland protocols and implement some mechanism so only dedicated clients can use ilm controler protocol.
Violin Yanev: What is the correct way to destroy a wayland-ivi-surface? Should it be destroyed before, or after the wayland-surface which was used to create it? How does a compositor react if the wayland-surface is destroyed, but the ivi-surface not?
Eugen Friedrich: The ivi surface should be destroyed first/before the wayland-surface, if the wayland-surface will be destroyed first also ivi surface is destroyed.