We're hiring!
*

Android: Enabling mainline graphics

Robert Foss avatar

Robert Foss
March 29, 2017

Share this post:

Android uses the HWC API to communicate with graphics hardware. This API is not supported on the mainline Linux graphics stack, but by using drm_hwcomposer as a shim it now is.

The HWC (Hardware Composer) API is used by SurfaceFlinger for compositing layers to the screen. The HWC abstracts objects such as overlays and 2D blitters and helps offload some work that would normally be done with OpenGL. SurfaceFlinger on the other hand accepts buffers from multiple sources, composites them, and sends them to the display.

Figure 1. The traditional Android graphics stack.


This is where drm_hwcomposer comes into play. Since the mainline kernel graphics stack doesn't offer the HWC API, drm_hwcomposer is introduced to interface with the mainline graphics stack through mesa and libdrm. Before this work drm_hwcomposer only offered the HWC1 API. Since Android 7.0 version 2 of the HWC API is used by SurfaceFlinger. HWC2 differs in a few ways from the previous version, for example the semantics of fence support were changed and the GPU can now be used as a fallback when compositing layers. Up until recently the mainline kernel lacked the fence primitive offered by Android used in HWC1 and HWC2.

But after my fellow Collaboran Gustavo Padovan's work on adding fence support to the mainline kernel was upstreamed in v4.10, the mainline kernel now has fence support equivalent to that of Android. The new fence support enabled work on drm_hwcomposer to add HWC2 support. And with it we are now able to boot Android on the db410c running the freedreno driver. But in theory it should work on any mainline kernel graphics stack enabled GPU. Currently the work is being upstreamed to the ChromiumOS repo which is the official upstream for drm_hwcomposer. A number of projects have seen contributions in order to enable this work:

  • kernel - sync_file, in-fence and out-fence support added.
  • libdrm - fence support added.
  • mesa - support for passing fences added.
  • intel-gpu-tools - sync and fence tests added.
  • drm_hwcomposer - HWC2 and fence support added.


Thanks

This drm_hwcomposer work is part of long-standing collaboration between Google's ChromeOS team and Collabora.

 

Original post

Comments (11)

  1. John :
    Mar 30, 2017 at 11:16 AM

    What are mainline graphics?

    What sort of real-world example would take advantage of this feature?

    E.G. do mainline graphics enable Android to use a Linux window manager/desktop?

    Thanks...

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Mar 30, 2017 at 05:20 PM

      Mainline graphics refers to the open source graphics stack (open source driver/mesa/libdrm etc).

      A real-world example is running Android on the Raspberry Pi using the normal open source drivers.

      No, this wouldnt allow you to allow you to run a regular Linux window manager/desktop on Android,
      but that should already be possible theoretically. Practically it surely would be a lot of work.

      Reply to this comment

      Reply to this comment

  2. Jayaraj Chanku:
    Mar 16, 2018 at 03:54 PM

    Hi Robert,
    Amazing information. After this read only I came to know that enabling the the open source graphics stack is this much easy and thanks for sharing this post.

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Mar 20, 2018 at 02:45 PM

      Hey Jayaraj,

      I'm glad this is useful to people, thanks for the feedback :)


      Rob.

      Reply to this comment

      Reply to this comment

  3. SummerOak:
    Jan 07, 2019 at 10:54 AM

    Hi Robert, Thanks for the article.
    I found the the codes of drm_hwcomposer has been included in AOSP, but never be compiled since no target defined BOARD_USES_DRM_HWCOMPOSER. How can I run the drm_hwcomposer under AOSP?

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Jan 07, 2019 at 05:11 PM

      Hey SummerOak,

      There are two ways to get started using drm_hwcomposer. Either using one of the linaro local_manifests[1] (which defines a 'flavor' of Android)
      or by using the Android-x86[2] project as a base.

      [1] https://github.com/linaro-swg/optee_android_manifest

      [2] http://www.android-x86.org/getsourcecode

      Reply to this comment

      Reply to this comment

      1. SummerOak:
        Jan 08, 2019 at 03:00 AM

        Hi, Robert. Thanks for your reply.
        Since I'm doing something base on AOSP and need it run on PC with ARM-arch CPU and specified GPU, So, both HiKey board and Android-x86 may not an appropriate environment to develop and debug.
        So I'm looking for a way to build a ARM-arch image based on AOSP with drm_hwcomposer enabled and run that image on my target PC(ARM-arch CPU + AMD GPU).
        The most hard work for me is to install the system image on PC and run it. Any suggestion?

        Reply to this comment

        Reply to this comment

        1. Robert Foss:
          Jan 08, 2019 at 05:31 PM

          Starting with a local_manifest that already uses drm_hwcomposer may be the easiest way to get started.
          If not, you'll have to create your own board-config and include the right versions of drm_hwcomposer/mesa/libdrm/gralloc and so on.

          Reply to this comment

          Reply to this comment

  4. Martin Fuzzey:
    Jan 23, 2020 at 08:54 PM

    If it could be useful for anyone I have created a git repo with the patches and config files to get Android running on mainline graphics.
    For the moment for I.mx6 Android 8.1 but others could be added.

    https://gitlab.freedesktop.org/martin.fuzzey/android-oss-gfx

    Reply to this comment

    Reply to this comment

    1. sabretest_:
      Jul 11, 2020 at 09:36 PM

      Thanks, this seems useful.

      Which local_manifest/linaro.xml did you use for android 8.1?

      Reply to this comment

      Reply to this comment

      1. Martin Fuzzey:
        Jul 15, 2020 at 09:31 AM

        Ah,
        the comment is out of date, I will fix that.
        That was true for android5, in android8 linaro.xml no longer includes libdrm.
        Linaro is not needed to get the graphics stack working, it just provides a few unrelated useful things like busybox and is available in the linaro-oreo branch of git://android.git.linaro.org/platform/manifest.git

        Reply to this comment

        Reply to this comment


Add a Comment






Allowed tags: <b><i><br>Add a new comment:


Search the newsroom

Latest Blog Posts

Adding VP9 and MPEG2 stateless support in v4l2codecs for GStreamer

23/06/2021

Earlier this year, from January to April 2021, I worked on adding support for stateless decoders for GStreamer as part of a multimedia internship…

Bag of Freebies for XR Hand Tracking: Machine Learning & OpenXR

17/06/2021

In our previous post, we presented a project backed by INVEST-AI which introduces a multi-stage neural network-based solution. Now let's…

Testing cameras with lc-compliance on KernelCI

15/06/2021

Initiated as a joint effort by the Google Chrome OS team and Collabora, the recent KernelCI hackfest brought the addition of new tests including…

Zink: Summer 2021 update

14/06/2021

There's a lot that has happened in the world of Zink since my last update, so let's see if I can bring you up to date on the most important…

Open Source OpenGL ES 3.1 on Mali GPUs with Panfrost

11/06/2021

Panfrost, the open source driver for Arm Mali, now supports OpenGL ES 3.1 on both Midgard (Mali T760 and newer) and Bifrost (Mali G31, G52,…

Optimizing 3D performance with virglrenderer

17/05/2021

Collabora has been investing into Perfetto to enable driver authors & users to get deep insights into driver internals and GPU performance.…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2021. All rights reserved. Privacy Notice. Sitemap.

Collabora Limited is registered in England and Wales. Company Registration number: 5513718. Registered office: The Platinum Building, St John's Innovation Park, Cambridge, CB4 0DS, United Kingdom. VAT number: 874 1630 19.