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.
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()