Page tree
Skip to end of metadata
Go to start of metadata

On this page the future improvements and current (v1.9) limitations of Wayland IVI Extension are discussed and some solutions to these problems are proposed. This page should be considered as place where the topics for the Roadmap should be mentioned and discussed

Setting some ivi-controller protocol parts as deprecated (relevant for Miranda release)

  • ivi_controller_surface_set_configuration
  • ivi_controller_surface_set_orientation
  • ivi_controller_surface_send_pixelformat
  • ivi_controller_surface_send_stats
  • ivi_controller_surface_send_content
  • ivi_controller_layer_set_configuration
  • ivi_controller_layer_set_orientation
  • ivi_controller_layer_screenshot
  • ivi_controller_send_error

Setting some ILM APIs as deprecated (relevant for Miranda release)

  • ilm_surfaceSetOrientation
  • ilm_surfaceGetOrientation
  • ilm_layerSetOrientation
  • ilm_layerGetOrientation
  • ilm_surfaceGetPixelformat
  • ilm_takeLayerScreenshot
  • ilmClient_init
  • ilm_surfaceCreate
  • ilm_surfaceRemove
  • ilmClient_destroy

Implementing DLT support (relevant for Miranda release)

We should use DLT for debug and error logging on the client side of the wayland-ivi-extension. We will not implement DLT logging in compositor because it might be hard to convince weston community to accept those implementation. Since DLT is a main Genivi logging and trace tooling it should be use in all Genivi components as much as possible to have a common channel for all traces.

Supporting composition of one surface on many displays (relevant for Miranda release)

In the multi display ivi environments, e.g. Rear-Seat-Entertainment, there are some use-case to present the same application on different displays at the same time. For example video play back of the same video on all available display even in different resolution. Implementing this feature in compositor is the best way to save memory and performance: a buffer prepared and send only once from application to the compositor and can be distribute this to several displays by taking into account positioning and scaling for particular display.

Some ideas of concrete implementation (currently discussed with weston community):

Extensive changes are needed for ivi-shell. The most basic approach would be that an ivi_surface would have a weston_view for every layer/screen combination. But ivi_layout API does not make much sense than. Because when controller calls ivi_layout_surface_set_destination_rectangle, should we scale all views ? I think it does not make sense to scale all views. Therefore, the set APIs should be changed to get ivi_views and not ivi_surfaces. This would mean:

  • Modifying every ivi_layout_surface_set* API
  • Implementing new APIs to get layer/screen specific ivi_views for a given ivi_surface
  • ivi-layers should list ivi_views and not ivi_surfaces
  • The implementation of commit_changes should be updated accordingly.

Hot-plug capability for displays (relevant for Miranda release)

Hot-plug of displays is supported in weston. Minimal effort is needed to support this also in ivi-shell. This functionality will be needed to support displays which can be switched on and off without restarting a compositor.

Predefined display-IDs (relevant for Miranda release)

In multi display environment it might be important to assign the same defined display id to a concrete physical connector and not relay on the order how they appear in the system (current implementation), the startup of the system should be assumed as not deterministic. This feature is important to ensure the main and the rear displays will always get the same ids, regardless in which order they are initialized.

Implementing ivi_controller_screen/layer/surface_sync requests

In current implementation, the changes of proporties of a surface/layer/screen are updated immediately. The compositor sends the according events every time when a property is changed. But these properties are only needed for ilm_surface/layer/screenGet* APIs which are rarely used. Because most system has a central HMI controller, and the HMI controller sets these properties in the first place.

Instead of sending these events immediately, we can introduce ivi_conttroller_*_sync requests which sends the actual properties of a screen/layer/surface when a get API for is called for the screen/layer/surface. The usage of this new request will considerably decrease the required socket communication between the HMI controller and the compositor. Moreover we also introduce something to support ilm_*AddNotification.

Multi ECU support

There are use cases for automotive as follows:
   - Transfers grapchic contents to other ECU. The ECU shows (composites) the transferred contents on own display. e.g. Rear-Seat-Entertainment shows map or video played on multimedia ECU.
   - Transfers input event back to "source" ECU issuing graphic contents. e.g. Back passenger operates map with touch screen of the RSE.
We will extend wayland IVI extension protocol for central HMI controller and wayland apps to handle such communication with less effort.

Synchronizing buffer resizing with destination rectangle resizing

TBD

Main loop integration

It make sense to provide a main loop integration possibility of the ilm_controller thread. Currently we have to create our own internal thread to dispatch all wayland events for the ivi-controller.xml protoca. With main loop integration application could just integrate the dispatching in their loop.



  • No labels