How Google's Android Runtime On Chrome OS Uses Wayland, DRM
Google developer David Reveman presented at this morning's XDC2016 conference in Finland about the Android Runtime for Chrome making use of Wayland (ARC++) and how the rest of its graphics stack looks for running Android programs on Chrome OS.
For rendering with ARC++, Gralloc and the OpenGL ES driver are using the Direct Rendering Manager, applications have full access to OpenGL ES, and there are support for other rendering APIs. Compositing with ARC++ is handled by the Android HWComposer and then surfaces are forwarded to Chrome for compositing with the rest of Chrome OS' user-interface.
ARC++ makes use of DRM with render-nodes for allowing the Android program to access the GPU and buffers are shared via DMA-BUF.
ARC++ makes use of Wayland when it comes to graphics / window manager / input communication between Android and Chrome. Wayland is used given its state on Linux as the "de facto protocol for secure compositor communication by Linux apps", new interfaces being easily added, and existing Wayland clients/code provide good examples and test-cases. Reveman noted, "Offers maximum code reuse and minimizes the attack surface if we were to enable more generic container support."
Beyond the core Wayland protocol, ARC++ / Chromium is making use of some additional extensions: wp_viewporter, XDG_Shell, wl_drm, and zwp_linux_dmabuf_v1. There are also Chromium-focused Wayland interfaces for alpha compositing, gaming input (game-pads currently), additional Aura shell functionality to complement XDG_Shell, secure outputs, an on-screen stylus extension, and vsync feedback information.
Google developers are also looking at working on Wayland extensions around explicit synchronization and protect buffers. The protected buffers support on Wayland is for digital rights management support.
Those wishing to learn more about the ARC++ / Chromium Wayland use and its graphics architecture beyond this quick summary I typed up, see the PDF presentation or you can watch David's entire session via the XDC2016 video stream.
For rendering with ARC++, Gralloc and the OpenGL ES driver are using the Direct Rendering Manager, applications have full access to OpenGL ES, and there are support for other rendering APIs. Compositing with ARC++ is handled by the Android HWComposer and then surfaces are forwarded to Chrome for compositing with the rest of Chrome OS' user-interface.
ARC++ makes use of DRM with render-nodes for allowing the Android program to access the GPU and buffers are shared via DMA-BUF.
ARC++ makes use of Wayland when it comes to graphics / window manager / input communication between Android and Chrome. Wayland is used given its state on Linux as the "de facto protocol for secure compositor communication by Linux apps", new interfaces being easily added, and existing Wayland clients/code provide good examples and test-cases. Reveman noted, "Offers maximum code reuse and minimizes the attack surface if we were to enable more generic container support."
Beyond the core Wayland protocol, ARC++ / Chromium is making use of some additional extensions: wp_viewporter, XDG_Shell, wl_drm, and zwp_linux_dmabuf_v1. There are also Chromium-focused Wayland interfaces for alpha compositing, gaming input (game-pads currently), additional Aura shell functionality to complement XDG_Shell, secure outputs, an on-screen stylus extension, and vsync feedback information.
Google developers are also looking at working on Wayland extensions around explicit synchronization and protect buffers. The protected buffers support on Wayland is for digital rights management support.
Those wishing to learn more about the ARC++ / Chromium Wayland use and its graphics architecture beyond this quick summary I typed up, see the PDF presentation or you can watch David's entire session via the XDC2016 video stream.
14 Comments