[RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available

[Stefan Schake]

Hey Eric,

On Thu, Feb 22, 2018 at 9:47 PM, Eric Anholt <eric at anholt.net> wrote:
> Stefan Schake <stschake at 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 <stschake at 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.

Thanks,
Stefan