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:

1. How Ramses-Renderer is rendering the scene?
   
   1. 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.

Pseudo code for RAMSES nested compositing

// ###### Process #1 - the nested compositor ##########

RamsesRenderer renderer;

// connect to system compositor
//create a ramses "display", which is essentially a wayland surface + EGL context
renderer.createDisplay("wayland-0")

// Create another wayland socket for incoming (nested) connections
renderer.createWaylandServer("wayland-1")

// starts showing black frames, because there is no content yet
renderer.startThread()

// Create scene setup
RamsesClient client;
Scene scene = client.createScene()
Quad quadLeft  = scene.createQuad(         0, 0, displayW/2, displayH)
Quad quadRight = scene.createQuad(displayW/2, 0, displayW/2, displayH)

// Mark the quads with IVI-ids, then the renderer will automatically link them with an IVI surface
// If the IVI surface is not connected (e.g. nested client crashed or disconnected), then show the "fallback texture"
Texture fallbackTexture = client.loadTexture("stream_unavailable.PNG")
scene.createStreamSurface(quadLeft,  IviId(11), fallbackTexture)
scene.createStreamSurface(quadRight, IviId(22), fallbackTexture)

// This is just pseudo code
// Full renderer API offers fine grained control over the scene state - memory, rendering, CPU budget etc.
renderer.showScene(scene)

// Rest of business logic, for example:
while(true)
    if(!renderer.iviStreamAvailable(22))
        quadLeft.makeFullscreen()
    else if(!renderer.iviStreamAvailable(11))
        quadRight.makeFullscreen()



// ###### Process #2 - the nested ivi client ##########

// This can be any arbitrary wayland-egl application, but it can be also another nested ramses compositor
wl_display display = wl_display_connect("wayland-1");
wl_surface = wl_compositor_create_surface();
wl_ivi_surface = ivi_application_surface_create(11, wl_surface); // or 22, for the second instance

OpenGL openGL;
openGL.renderSomeContent()