Android assumes an implicit black background layer is always present
behind all layers it specifies for composition. drm_hwcomposer currently
punts responsibility for this to the kernel/DRM platform and puts layers
with per-pixel alpha content on the primary plane when requested.

Advertising

I wasn't aware of this assumption, but given that it is the case,
the patch looks like a good fix for the problem.

Unfortunately I don't have a hardware platform up and running to test the patch
with at the moment.

On some platforms (e.g. VC4) a background color fill has a cycle cost for
the hardware composer and is not enabled by default. Instead, userland can
request a background color through a CRTC property. Use this property to
specify the implicit black background Android expects.
Signed-off-by: Stefan Schake <stsch...@gmail.com>
---
Kernel changes for this (background_color) are available here:
https://github.com/stschake/linux/commits/background-upstream
Sending as RFC because I'm not entirely clear on whose responsibility
this should be, on most DRM drivers it seems to be implicit. I think
a case could also be made that VC4 should not accept alpha formats on
the lowest layer or enable background color fill when given one anyway.
On the other hand, userland control over background color seems desirable
regardless and is a feature of multiple hardware composers (i915, vc4, omap).
drmcrtc.cpp | 11 +++++++++++
drmcrtc.h | 2 ++
drmdisplaycompositor.cpp | 15 +++++++++++++++
3 files changed, 28 insertions(+)
diff --git a/drmcrtc.cpp b/drmcrtc.cpp
index 1b354fe..d7bcd7a 100644
--- a/drmcrtc.cpp
+++ b/drmcrtc.cpp
@@ -52,6 +52,13 @@ int DrmCrtc::Init() {
ALOGE("Failed to get OUT_FENCE_PTR property");
return ret;
}
+
+ ret = drm_->GetCrtcProperty(*this, "background_color",
+ &background_color_property_);
+ if (ret) {
+ ALOGI("Failed to get background_color property");
+ // This is an optional property
+ }
return 0;
}