All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available
@ 2018-02-22  3:54 Stefan Schake
  2018-02-22 10:04 ` Robert Foss
                   ` (3 more replies)
  0 siblings, 4 replies; 12+ messages in thread
From: Stefan Schake @ 2018-02-22  3:54 UTC (permalink / raw)
  To: dri-devel; +Cc: Stefan Schake

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@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;
 }
 
@@ -86,4 +93,8 @@ const DrmProperty &DrmCrtc::mode_property() const {
 const DrmProperty &DrmCrtc::out_fence_ptr_property() const {
   return out_fence_ptr_property_;
 }
+
+const DrmProperty &DrmCrtc::background_color_property() const {
+  return background_color_property_;
+}
 }
diff --git a/drmcrtc.h b/drmcrtc.h
index c5a5599..704573a 100644
--- a/drmcrtc.h
+++ b/drmcrtc.h
@@ -46,6 +46,7 @@ class DrmCrtc {
   const DrmProperty &active_property() const;
   const DrmProperty &mode_property() const;
   const DrmProperty &out_fence_ptr_property() const;
+  const DrmProperty &background_color_property() const;
 
  private:
   DrmResources *drm_;
@@ -59,6 +60,7 @@ class DrmCrtc {
   DrmProperty active_property_;
   DrmProperty mode_property_;
   DrmProperty out_fence_ptr_property_;
+  DrmProperty background_color_property_;
 };
 }
 
diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
index e556e86..69c52dd 100644
--- a/drmdisplaycompositor.cpp
+++ b/drmdisplaycompositor.cpp
@@ -527,6 +527,21 @@ int DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
       return ret;
     }
 
+    if (crtc->background_color_property().id() != 0) {
+      // Background color is specified as a 16 bit per channel RGBA value.
+      // Set a fully opaque black background as Android HWC expects.
+      const uint64_t background_color = 0xFFFF;
+
+      ret = drmModeAtomicAddProperty(pset, crtc->id(),
+                                     crtc->background_color_property().id(),
+                                     background_color) < 0;
+      if (ret) {
+        ALOGE("Failed to add CRTC background_color to pset: %d", ret);
+        drmModeAtomicFree(pset);
+        return ret;
+      }
+    }
+
     ret = drmModeAtomicAddProperty(pset, crtc->id(), crtc->mode_property().id(),
                                    mode_.blob_id) < 0 ||
           drmModeAtomicAddProperty(pset, connector->id(),
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available
  2018-02-22  3:54 [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available Stefan Schake
@ 2018-02-22 10:04 ` Robert Foss
  2018-02-22 12:23   ` Stefan Schake
  2018-02-22 20:47 ` Eric Anholt
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 12+ messages in thread
From: Robert Foss @ 2018-02-22 10:04 UTC (permalink / raw)
  To: Stefan Schake, dri-devel

Hey Stefan,

On 02/22/2018 04:54 AM, Stefan Schake wrote:
> 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.

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 <stschake@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;
>   }
>   
> @@ -86,4 +93,8 @@ const DrmProperty &DrmCrtc::mode_property() const {
>   const DrmProperty &DrmCrtc::out_fence_ptr_property() const {
>     return out_fence_ptr_property_;
>   }
> +
> +const DrmProperty &DrmCrtc::background_color_property() const {
> +  return background_color_property_;
> +}
>   }
> diff --git a/drmcrtc.h b/drmcrtc.h
> index c5a5599..704573a 100644
> --- a/drmcrtc.h
> +++ b/drmcrtc.h
> @@ -46,6 +46,7 @@ class DrmCrtc {
>     const DrmProperty &active_property() const;
>     const DrmProperty &mode_property() const;
>     const DrmProperty &out_fence_ptr_property() const;
> +  const DrmProperty &background_color_property() const;
>   
>    private:
>     DrmResources *drm_;
> @@ -59,6 +60,7 @@ class DrmCrtc {
>     DrmProperty active_property_;
>     DrmProperty mode_property_;
>     DrmProperty out_fence_ptr_property_;
> +  DrmProperty background_color_property_;
>   };
>   }
>   
> diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
> index e556e86..69c52dd 100644
> --- a/drmdisplaycompositor.cpp
> +++ b/drmdisplaycompositor.cpp
> @@ -527,6 +527,21 @@ int DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
>         return ret;
>       }
>   
> +    if (crtc->background_color_property().id() != 0) {
> +      // Background color is specified as a 16 bit per channel RGBA value.
> +      // Set a fully opaque black background as Android HWC expects.
> +      const uint64_t background_color = 0xFFFF;
> +
> +      ret = drmModeAtomicAddProperty(pset, crtc->id(),
> +                                     crtc->background_color_property().id(),
> +                                     background_color) < 0;
> +      if (ret) {
> +        ALOGE("Failed to add CRTC background_color to pset: %d", ret);
> +        drmModeAtomicFree(pset);
> +        return ret;
> +      }
> +    }
> +
>       ret = drmModeAtomicAddProperty(pset, crtc->id(), crtc->mode_property().id(),
>                                      mode_.blob_id) < 0 ||
>             drmModeAtomicAddProperty(pset, connector->id(),
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available
  2018-02-22 10:04 ` Robert Foss
@ 2018-02-22 12:23   ` Stefan Schake
  0 siblings, 0 replies; 12+ messages in thread
From: Stefan Schake @ 2018-02-22 12:23 UTC (permalink / raw)
  To: Robert Foss; +Cc: dri-devel

Hey Robert,

On Thu, Feb 22, 2018 at 11:04 AM, Robert Foss <robert.foss@collabora.com> wrote:
> Hey Stefan,
>
> On 02/22/2018 04:54 AM, Stefan Schake wrote:
>>
>> 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.
>
>
> 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.
>

HWC1 has this ominous comment:

* IMPORTANT NOTE: There is an implicit layer containing opaque black
* pixels behind all the layers in the list. It is the responsibility of
* the hwcomposer module to make sure black pixels are output (or blended
* from).

It's not repeated in the HWC2 docs, but I think the assumption carried over
given that Android prefers all things RGBA. Admittedly it's rare that you
don't have a full-size opaque layer in the composition like a background
picture, so the cases where this causes corrupted rendering on VC4 are limited
to some time during boot after the animation finishes but the launcher isn't
up yet.

Thanks,
Stefan
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available
  2018-02-22  3:54 [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available Stefan Schake
  2018-02-22 10:04 ` Robert Foss
@ 2018-02-22 20:47 ` Eric Anholt
  2018-02-23 14:34   ` Stefan Schake
  2018-03-06  7:46 ` Daniel Vetter
  2018-06-29 10:05 ` Maarten Lankhorst
  3 siblings, 1 reply; 12+ messages in thread
From: Eric Anholt @ 2018-02-22 20:47 UTC (permalink / raw)
  To: dri-devel; +Cc: Stefan Schake


[-- Attachment #1.1: Type: text/plain, Size: 1581 bytes --]

Stefan Schake <stschake@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@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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available
  2018-02-22 20:47 ` Eric Anholt
@ 2018-02-23 14:34   ` Stefan Schake
  2018-02-28 10:53     ` Robert Foss
  0 siblings, 1 reply; 12+ messages in thread
From: Stefan Schake @ 2018-02-23 14:34 UTC (permalink / raw)
  To: Eric Anholt; +Cc: dri-devel

Hey Eric,

On Thu, Feb 22, 2018 at 9:47 PM, Eric Anholt <eric@anholt.net> wrote:
> Stefan Schake <stschake@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@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available
  2018-02-23 14:34   ` Stefan Schake
@ 2018-02-28 10:53     ` Robert Foss
  2018-03-02  0:41       ` Stefan Schake
  0 siblings, 1 reply; 12+ messages in thread
From: Robert Foss @ 2018-02-28 10:53 UTC (permalink / raw)
  To: Stefan Schake, Eric Anholt; +Cc: dri-devel

Hey,

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

To me Erics solution sounds pragmatic, and would be easy to reason about going 
forward. Making sure that all of the kernel drivers behave the same way might be 
the hardest part.

Stefan: Are you looking at an entirely kernel side fix now, or are you pushing 
this series forward?


Rob.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available
  2018-02-28 10:53     ` Robert Foss
@ 2018-03-02  0:41       ` Stefan Schake
  2018-03-02 14:34         ` Robert Foss
  0 siblings, 1 reply; 12+ messages in thread
From: Stefan Schake @ 2018-03-02  0:41 UTC (permalink / raw)
  To: Robert Foss; +Cc: dri-devel

Hey Rob,

On Wed, Feb 28, 2018 at 11:53 AM, Robert Foss <robert.foss@collabora.com> wrote:
> Hey,
>
> Stefan: Are you looking at an entirely kernel side fix now, or are you
> pushing this series forward?

I've sent out a kernel side fix for this:

https://patchwork.freedesktop.org/patch/207667/

So I guess for now this can be dropped, pending review.

Thanks,
Stefan
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available
  2018-03-02  0:41       ` Stefan Schake
@ 2018-03-02 14:34         ` Robert Foss
  0 siblings, 0 replies; 12+ messages in thread
From: Robert Foss @ 2018-03-02 14:34 UTC (permalink / raw)
  To: Stefan Schake; +Cc: dri-devel

Ack, thanks for the heads up!


Rob.

On 03/02/2018 01:41 AM, Stefan Schake wrote:
> Hey Rob,
> 
> On Wed, Feb 28, 2018 at 11:53 AM, Robert Foss <robert.foss@collabora.com> wrote:
>> Hey,
>>
>> Stefan: Are you looking at an entirely kernel side fix now, or are you
>> pushing this series forward?
> 
> I've sent out a kernel side fix for this:
> 
> https://patchwork.freedesktop.org/patch/207667/
> 
> So I guess for now this can be dropped, pending review.
> 
> Thanks,
> Stefan
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available
  2018-02-22  3:54 [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available Stefan Schake
  2018-02-22 10:04 ` Robert Foss
  2018-02-22 20:47 ` Eric Anholt
@ 2018-03-06  7:46 ` Daniel Vetter
  2018-06-29 10:05 ` Maarten Lankhorst
  3 siblings, 0 replies; 12+ messages in thread
From: Daniel Vetter @ 2018-03-06  7:46 UTC (permalink / raw)
  To: Stefan Schake; +Cc: dri-devel

On Thu, Feb 22, 2018 at 04:54:08AM +0100, Stefan Schake wrote:
> 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@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).

I see you've already typed vc4 patches to address, just wanted to clarify
this here: The assumption is that all drivers already have a background
color of black/0. The background color property would be to set a
different background color than black.

If the driver has undefined behaviour for instead of an assumed background
color of black, then I think that's a driver bug.

See https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-composition-properties

"(e.g. for the background color, which currently is not exposed and
assumed to be black)"

I'm still hoping for some artist to create a nice svg that explains the
kms composition model with a nice graphic ...

Cheers, Daniel

> 
>  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;
>  }
>  
> @@ -86,4 +93,8 @@ const DrmProperty &DrmCrtc::mode_property() const {
>  const DrmProperty &DrmCrtc::out_fence_ptr_property() const {
>    return out_fence_ptr_property_;
>  }
> +
> +const DrmProperty &DrmCrtc::background_color_property() const {
> +  return background_color_property_;
> +}
>  }
> diff --git a/drmcrtc.h b/drmcrtc.h
> index c5a5599..704573a 100644
> --- a/drmcrtc.h
> +++ b/drmcrtc.h
> @@ -46,6 +46,7 @@ class DrmCrtc {
>    const DrmProperty &active_property() const;
>    const DrmProperty &mode_property() const;
>    const DrmProperty &out_fence_ptr_property() const;
> +  const DrmProperty &background_color_property() const;
>  
>   private:
>    DrmResources *drm_;
> @@ -59,6 +60,7 @@ class DrmCrtc {
>    DrmProperty active_property_;
>    DrmProperty mode_property_;
>    DrmProperty out_fence_ptr_property_;
> +  DrmProperty background_color_property_;
>  };
>  }
>  
> diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
> index e556e86..69c52dd 100644
> --- a/drmdisplaycompositor.cpp
> +++ b/drmdisplaycompositor.cpp
> @@ -527,6 +527,21 @@ int DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
>        return ret;
>      }
>  
> +    if (crtc->background_color_property().id() != 0) {
> +      // Background color is specified as a 16 bit per channel RGBA value.
> +      // Set a fully opaque black background as Android HWC expects.
> +      const uint64_t background_color = 0xFFFF;
> +
> +      ret = drmModeAtomicAddProperty(pset, crtc->id(),
> +                                     crtc->background_color_property().id(),
> +                                     background_color) < 0;
> +      if (ret) {
> +        ALOGE("Failed to add CRTC background_color to pset: %d", ret);
> +        drmModeAtomicFree(pset);
> +        return ret;
> +      }
> +    }
> +
>      ret = drmModeAtomicAddProperty(pset, crtc->id(), crtc->mode_property().id(),
>                                     mode_.blob_id) < 0 ||
>            drmModeAtomicAddProperty(pset, connector->id(),
> -- 
> 2.7.4
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available
  2018-02-22  3:54 [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available Stefan Schake
                   ` (2 preceding siblings ...)
  2018-03-06  7:46 ` Daniel Vetter
@ 2018-06-29 10:05 ` Maarten Lankhorst
  2018-06-29 10:27   ` Stefan Schake
  3 siblings, 1 reply; 12+ messages in thread
From: Maarten Lankhorst @ 2018-06-29 10:05 UTC (permalink / raw)
  To: Stefan Schake, dri-devel

Op 22-02-18 om 04:54 schreef Stefan Schake:
> 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@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).
Ping? Would be nice if we were moving forward. :)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available
  2018-06-29 10:05 ` Maarten Lankhorst
@ 2018-06-29 10:27   ` Stefan Schake
  2018-07-02 12:22     ` Maarten Lankhorst
  0 siblings, 1 reply; 12+ messages in thread
From: Stefan Schake @ 2018-06-29 10:27 UTC (permalink / raw)
  To: Maarten Lankhorst; +Cc: dri-devel

Hey Maarten,

On Fri, Jun 29, 2018 at 12:05 PM, Maarten Lankhorst
<maarten.lankhorst@linux.intel.com> wrote:
> Op 22-02-18 om 04:54 schreef Stefan Schake:
>> 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@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).
> Ping? Would be nice if we were moving forward. :)

I was unclear if DRM specified a black background when writing this.
Someone pointed me towards the excerpt in the docs that explicitly
mandates black background fill and so I ended up writing a VC4 patch
that automatically sets it when required instead of the optional property
used here.

Adding a background_color property would still be desirable, but I'm
unclear on what the userspace would be at the moment. drm_hwc doesn't
need any background color other than black and since that is the DRM
default, it wouldn't need to use a property.

Thanks,
Stefan
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available
  2018-06-29 10:27   ` Stefan Schake
@ 2018-07-02 12:22     ` Maarten Lankhorst
  0 siblings, 0 replies; 12+ messages in thread
From: Maarten Lankhorst @ 2018-07-02 12:22 UTC (permalink / raw)
  To: Stefan Schake; +Cc: dri-devel

Op 29-06-18 om 12:27 schreef Stefan Schake:
> Hey Maarten,
>
> On Fri, Jun 29, 2018 at 12:05 PM, Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com> wrote:
>> Op 22-02-18 om 04:54 schreef Stefan Schake:
>>> 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@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).
>> Ping? Would be nice if we were moving forward. :)
> I was unclear if DRM specified a black background when writing this.
> Someone pointed me towards the excerpt in the docs that explicitly
> mandates black background fill and so I ended up writing a VC4 patch
> that automatically sets it when required instead of the optional property
> used here.
>
> Adding a background_color property would still be desirable, but I'm
> unclear on what the userspace would be at the moment. drm_hwc doesn't
> need any background color other than black and since that is the DRM
> default, it wouldn't need to use a property.
>
> Thanks,
> Stefan

It would still be useful for e-paper displays where the background color would be better suited
as white, or when we want to blend a different color than black. But I fear for now there's no
real userspace. :(

Which is unfortunate, because the series are easy to implement, but it's just a case where there's
no need from userspace yet for the hw capability.

~Maarten

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2018-07-02 12:22 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-22  3:54 [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available Stefan Schake
2018-02-22 10:04 ` Robert Foss
2018-02-22 12:23   ` Stefan Schake
2018-02-22 20:47 ` Eric Anholt
2018-02-23 14:34   ` Stefan Schake
2018-02-28 10:53     ` Robert Foss
2018-03-02  0:41       ` Stefan Schake
2018-03-02 14:34         ` Robert Foss
2018-03-06  7:46 ` Daniel Vetter
2018-06-29 10:05 ` Maarten Lankhorst
2018-06-29 10:27   ` Stefan Schake
2018-07-02 12:22     ` Maarten Lankhorst

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.