Skip to content

RFC: Waltham Transmitter Backend

Veeresh Kadasani requested to merge VKadasani/weston:waltham-transmitter-backend-v1 into main

Introduction

This RFC describes a new Weston backend called “Waltham-transmitter backend” which uses the Waltham IPC protocol to connect to remote ECU and allows client buffer to be shared over gstreamer framework and rendered on remote ECU. Details of Waltham component in brief

• Waltham: A library which implements the communication between Waltham client and waltham server

• Waltham-client: Here new “Waltham-transmitter backend” act as Waltham-client which has direct access to application buffer (Weston client) and uses waltham-renderer [in current implementation this is gstreamer] which gets fd for the renderer buffer and creates gstreamer buffer from it and adds necessary metadata to transmit the buffer to Waltham-server

• Waltham-server [also called as Waltham-receiver]: This component handles the connection with Waltham-client, receives the buffer and responsible to provide the buffer to compositor. In simple words this is just like Weston ivi client which acts as proxy client to get buffer from Waltham-client and send to compositor.

Purpose

Modern IVI system are distributed, multi-display/multi-ECU (eg. Main IVI-head unit, Rear-seat-entertainment and cluster). With this modern system it becomes necessary for the graphics contents to be shared between ECU’s. Waltham-transmitter backend provide one such way to surface sharing. Comments are very welcome for this pull request.

This patch includes:

  • Transmitter uses Waltham IPC library to connect with remote ECU.
  • Creates a new wayland ouput which resembles a virtual screen.
  • Adding layer and surfaces to the transmitter output starts the remoting of surface.
  • Handles Input events from the remote ECU
  • Per surface and multi surface composition sharing.

Features

  • Per surface sharing meaning that a single client surface can be shared instead whole screen dynamic switching of client surface is also possible. You do this by just adding the surface to transmitter screen.
  • Input handling of remoted surface.
  • Gstreamer pipeline are configurable, that is both hardware based and software based pipeline can be used (e.g jpegenc/dec, omxenc/dec and mfxenc/dec) by modifying transmitter_pipeline.cfg under /etc/xdg/weston/.
  • Multi surface composition sharing is supported.
  • Transmitting to multi ECUs is supported. This can be done by adding multiple transmitter-output in weston.ini file.
[transmitter-output]
output-name=transmitter_1
server-address=192.168.2.11
port=34400
width=1920
height=1080
 
[transmitter-output]
output-name=transmitter_2
server-address=192.168.2.12
port=35500
width=1920
height=1080

Limitation

  • This is standalone backend now meaning client running on the transmitter will be seen rendered on the receiver ECU display and not on the transmitter side display.

Future plans

  • Make Weston run as multiple backend. This allows us to load both drm and transmitter backend simultaneously and different surface can rendered on HDMI display and also remoted and shown on receiver display at same time.

Merge request reports