Re: [PATCH v4 2/3] drm: Add CRTC background color property (v4)

[Brian Starkey <Brian.Starkey@arm.com>]

Hi Matt,

On Fri, Dec 28, 2018 at 03:51:30PM -0800, Matt Roper wrote:
> Some display controllers can be programmed to present non-black colors
> for pixels not covered by any plane (or pixels covered by the
> transparent regions of higher planes).  Compositors that want a UI with
> a solid color background can potentially save memory bandwidth by
> setting the CRTC background property and using smaller planes to display
> the rest of the content.
> 
> To avoid confusion between different ways of encoding RGB data, we
> define a standard 64-bit format that should be used for this property's
> value.  Helper functions and macros are provided to generate and dissect
> values in this standard format with varying component precision values.
> 
> v2:
>  - Swap internal representation's blue and red bits to make it easier
>    to read if printed out.  (Ville)
>  - Document bgcolor property in drm_blend.c.  (Sean Paul)
>  - s/background_color/bgcolor/ for consistency between property name and
>    value storage field.  (Sean Paul)
>  - Add a convenience function to attach property to a given crtc.
> 
> v3:
>  - Restructure ARGB component extraction macros to be easier to
>    understand and enclose the parameters in () to avoid calculations
>    if expressions are passed.  (Sean Paul)
>  - s/rgba/argb/ in helper function/macro names.  Even though the idea is
>    to not worry about the internal representation of the u64, it can
>    still be confusing to look at code that uses 'rgba' terminology, but
>    stores values with argb ordering.  (Ville)
> 
> v4:
>  - Drop the bgcolor_changed flag.  (Ville, Brian Starkey)
>  - Clarify in kerneldoc that background color is expected to undergo the
>    same pipe-level degamma/csc/gamma transformations that planes do.
>    (Brian Starkey)
>  - Update kerneldoc to indicate non-opaque colors are allowed, but are
>    generally only useful in special cases such as when writeback
>    connectors are used (Brian Starkey / Eric Anholt)

The updates LGTM.

Reviewed-by: Brian Starkey <brian.starkey@arm.com>

It would be good to see the Chrome implementation when you have it to
share.

Cheers,
-Brian

> 
> Cc: dri-devel@lists.freedesktop.org
> Cc: wei.c.li@intel.com
> Cc: harish.krupo.kps@intel.com
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: Brian Starkey <Brian.Starkey@arm.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Stéphane Marchesin <marcheu@chromium.org>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> Reviewed-by(v2): Sean Paul <sean@poorly.run>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx