Running Android on the Mainline Graphics Stack
summary
Mainline kernel gains DRM Atomic Modesetting and Explicit Synchronization (fences) plus userspace changes in drm_hwcomposer and Mesa, enabling Android’s HWComposer protocol to talk to DRM. The implementation uses kernel fences to avoid tricky threading, offloads composition onto display planes when hardware supports ~4 planes to save CPU/GPU, and falls back to GPU/CPU blending when needed. Upstream work (starting around 2016) makes Qualcomm, i.MX and Intel platforms run Android on the mainline graphics stack successfully.
AI-written summary · about
chapters (20)
- 0:00Android on mainline graphics
- 1:04Why Android needed own stack
- 2:16Mainline kernel limits for graphics
- 4:09Android’s atomic display attempt
- 5:55Atomic modesetting as solution
- 7:42Android graphics stack overview
- 10:20SurfaceFlinger and HWC work
- 13:38Hardware composition saves power
- 14:41Mainline ABI support status
- 16:04DRM HWC2 open-source replacement
- 19:13Fences in graphics pipelines
- 21:19Kernel support for fences/HWC2
- 22:49DRM HWC2 development history
- 23:54Platforms running Android on mainline
- 26:10Android features to kernel
- 28:17Challenges with proprietary drivers
- 29:58Vendor kernel strategies
- 31:43Open-source vs proprietary drivers
- 32:25Making Android accessible
- 33:07Q&A
related talks
24mRunning Android on the Mainline Graphics Stack
41mUnifying Android and Mainline Kernel Graphics Stack
05mTalks Android, ARM and LWN
15mCan mainline Linux run on Android without vendor hooks
01h 08mAndroid Plateform Anatomy
38mMainline Linux on AmLogic SoCs
32mThe Modern Linux Graphics Stack on Embedded Systems
09mAndroid Kernel Upstreaming to the Linux Kernel