We're hiring!
*

A dream come true: Android is finally using DRM/KMS

Gustavo Padovan avatar

Gustavo Padovan
December 17, 2018

Share this post:

In the beginning, Android did not really have a graphics stack. It was just pushing frames directly to framebuffers and hoping for the best, the approach worked for quite some time.

However, over time, the usecases became more and more complex and a new graphics stack was necessary. About 6 years ago the Android team conducted a lot of research and quickly realized that the mainline kernel was far from being up to the job - it was lacking Atomic screen updates, explicit syncronization and support for low power hardware, among other things. Google was left with no other choice than to design their own graphic stack: Atomic Display Framework (ADF).

That was another piece of the mainline linux kernel that Android forked, but it allowed Google to overcome the challenges brought on by the new needs of industry and customers.

The mainline graphics stack had a number of problems and the API was outdated and not keeping pace with the industry. The mainline graphics community knew it was time for an upgrade!

Atomic Modeset

The addition of Kernel Modeset (KMS) around 2008 was a revolution in itself, but as time passed, new needs arose and a new API was required. That lead to a situation where we had different syscalls to update every single buffer on the screen. In order to update the whole screen, for example, one would need to make a couple of syscalls and hope they would all be applied to the display hardware before the next vsync signal, otherwise some user noticeable flickering could happen. Unfortunately, such flickering was happening quite often.

Led by Daniel Vetter (Intel), the introduction of Atomic Modesetting on top of KMS in 2015 added a new system call that would contain *all* the information to update all buffers in all screens in a single commit transaction, fixing the issues that plagued the previous API. The Direct Rendering Manager (DRM) Core went through a comprehensive refactoring process, and drivers became much easier to write, allowing for all the major drivers to be eventually ported to atomic modesetting, and many more added as well, some of them with Collabora's help.

Explicit Synchronization

Atomic Modeset was a giant step but there was still one piece missing: Explicit Synchronization. To avoid screen stalls and lack of knowledge about the current state of a buffer, ADF from Android introduced sync fences to keep track of buffer state and signal when GPU or Display is done filling or scanning it out.

In work led by Collabora, the Android Sync Framework was refactored and added to the mainline kernel, and Explicit Synchronization support was coded into DRM Atomic Modeset. The kernel now had all the pieces to support Android running on DRM/KMS.

A new reality

The dream finally came true in 2018 with the release of the Google Pixel 3, the first Android phone running with the mainline graphics stack. A feat that was deemed impossible 10 years ago is now a reality thanks to a lot of hard work from the entire community.

Google ChromeOS also benefited from Explicit Synchronization to improve support for Android apps on Chromebooks, and now the Chrome Browser also has Explicit Synchronization support.

As more vendors start to push their code to mainline, and follow upstream closely, we expect others Android phone vendors to switch to DRM/KMS too in the future. The upstream stack is now quite modern and robust, and the benefits of using it is becoming clear!

Comments (5)

  1. MgcLabs:
    Dec 17, 2018 at 06:22 PM

    So now I wonder what major stuff is Out of Tree and if much, how far we are from having a completely mainline Android. I don't mean Android's userland being in the kernel obviously..I mean all Android phones running mainline Linux kernel

    Reply to this comment

    Reply to this comment

    1. mjblenner:
      Dec 17, 2018 at 09:42 PM

      Have a look at

      https://source.android.com/devices/architecture/kernel/android-common

      "When compared to LTS (4.14.0), the Android common kernel has 355 changes, 32266 insertions, and 1546 deletions (as of February 2018)"

      Most of the out of tree stuff seems to be drivers, with a big chunk of energy aware scheduling.

      Reply to this comment

      Reply to this comment

    2. Michael:
      Dec 17, 2018 at 09:50 PM

      This LWN article deals with what still needs to be done to get Android running on the mainline kernel:
      https://lwn.net/Articles/771974/

      Reply to this comment

      Reply to this comment

  2. amehaye:
    Dec 17, 2018 at 07:53 PM

    I guess that some of the major obstacles remaining are supporting the various cameras out there, as well as all the hardware media coders/decoders.

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Dec 18, 2018 at 10:00 AM

      Drivers are indeed a large part of whats left, but some drivers like those for finger print readers for example will likely never be upstreamed since the driver does little more than uploadinggg an encrypted firmware blob to the device.

      But if you look at the Android Commons kernel and compare them to the kernel LTS releases the number non-upstreamed patches should be small, on the order of 300 and shrinking.

      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

Virglrenderer and the state of virtualized virtual worlds

28/08/2019

With the release of virglrenderer 0.8.0, getting accelerated OpenGL within a virtual machine (VM) made a big leap forward. Since virglrenderer-0.7.0,…

ROCK Pi and an easy place: Panfrost & Wayland on a Rockchip board

06/08/2019

Ongoing work on the reverse-engineered Panfrost OpenGL ES driver for Arm Mali GPUs has turned the RK3399 SoC into a very attractive platform…

What's new in OpenXR 1.0 & Monado?

02/08/2019

As part of its unwavering commitment to open source and open standards, Collabora is proud to be part of bringing the recently-released…

Zink: Summer Update & SIGGRAPH 2019

25/07/2019

There's been quite a few updates to Zink, an OpenGL implementation on top of Vulkan, since I last wrote about it. Here's an overview of…

GStreamer in Oslo

18/07/2019

A little over a month and a half ago, Collaborans including Aaron Boxer, George Kiagiadakis, Guillaume Desmottes, Stéphane Cerveau and myself…

GNOME meets Panfrost

26/06/2019

In my last Panfrost blog post, I announced my internship goal: improve Panfrost to run GNOME3. GNOME is a popular Linux desktop making heavy…

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-2019. All rights reserved. Website sitemap.