Two major graphics architectures as of today (2019) are solving the same problem but in different way.
During a discussion in the spring AMM of 2019, several people expressed interest in understanding how the traditional Linux graphics approaches can be combined with the interest in Android for Automotive. Looking at the entire car electrical system we already see Android being introduced and combined with other systems; combined in the sense that it is communicating with other ECUs or placed on a single hardware using virtualization.
In addition to this there is of course the opportunity to run traditional GNU/Linux software stacks in parallel with Android stacks on a single Linux Kernel instance. This could be done either by custom changes that combine software components from each project, optionally combined with namespace/container methods.
The GSHA project participants expressed interest in investigating the different approaches, to create flexible building blocks and combinations of GNU/Linux and Android style systems. This future outlook is of interest also beyond graphics but in this group we focus first on the graphics and HMI composition components.
- Flexibility of solutions and learning from each solution benefits ecosystems.
- The desired features of a particular system might be achieved through other means than wholesale adoption of a new operating system.
- "Legacy" (or often also preferred) existing graphics intensive systems on Linux can be reused also for companies considering Android-based headunits.
- Some of the more powerful features of Wayland compositing are appreciated. Multiple and innovative Wayland-compositor implementations exist (such as the possibilities created by the QtWayland building blocks)
- The investigation we have into Wayland/Waltham standard for networking between a pure Linux system and a pure Android system (noted as number 1. below) will also benefit from such investigation.
The idea is to look into both Wayland and Surfaceflinger/Android approaches and try to harmonize or at least to understand how Android and Wayland Graphical system could collaborate with each other. The focus of this work will be related to the graphical memory allocations, 3D/2D rendering and window management.
- Surface Sharing between ECUs (or VMs): Can we use Wayland (Waltham) as a standard network protocol for Surface Sharing?
We have started in an earlier stage to discuss the applicability of Wayland+Waltham as a network exchange standard usable also to/from Android systems. This started with an (incomplete) comparison of Wayland vs Surfaceflinger APIs.
- "Hybrid system", alt 1: Running Android display subsystem as a wayland client based system.
- "Hybrid system", alt 2: `Wayland application on Android`, i.e. run wayland client applications but use Surfaceflinger as the primary compositor.
- "Split system" where each software stack is running mostly independently and graphical output is either on separate displays, or combined through GPU Sharing, Display Sharing (hardware layers or other). This could be implemented with a Hypervisor or using Linux containers.
Early brainstorm of 2. and 3 (relatively unorganized) can be read before the detailed pages linked above.