Hey Eric,

On Thu, Feb 22, 2018 at 9:47 PM, Eric Anholt <e...@anholt.net> wrote:
> Stefan Schake <stsch...@gmail.com> writes:
>> 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.
>> 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).
> Couldn't we just ignore the alpha channel on the primary plane, on the
> assumption that it's supposed to be all zeroes below it?  Or are we not
> premultiplied, so we do still need to multiply the primary plane's
> colors by the alpha value?  I couldn't find any obvious DRM
> documentation about whether alpha is premultiplied.

That would work, too (for a black background anyway). Though the easiest place
to spoof this is presumably in the kernel. From what I have seen, everything in
Android is already premultiplied, but technically it can specify
either. Not sure if this
is correctly handled in drm_hwcomposer yet.

dri-devel mailing list

Reply via email to