[Intel-gfx] [PATCH v4 2/3] drm: Add CRTC background color property (v4)
Brian Starkey
Brian.Starkey at arm.com
Mon Jan 7 11:08:04 UTC 2019
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 at arm.com>
It would be good to see the Chrome implementation when you have it to
share.
Cheers,
-Brian
>
> Cc: dri-devel at lists.freedesktop.org
> Cc: wei.c.li at intel.com
> Cc: harish.krupo.kps at intel.com
> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> Cc: Sean Paul <sean at poorly.run>
> Cc: Brian Starkey <Brian.Starkey at arm.com>
> Cc: Eric Anholt <eric at anholt.net>
> Cc: Stéphane Marchesin <marcheu at chromium.org>
> Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> Signed-off-by: Matt Roper <matthew.d.roper at intel.com>
> Reviewed-by(v2): Sean Paul <sean at poorly.run>
More information about the Intel-gfx
mailing list