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@xxxxxxx> It would be good to see the Chrome implementation when you have it to share. Cheers, -Brian > > Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx > Cc: wei.c.li@xxxxxxxxx > Cc: harish.krupo.kps@xxxxxxxxx > Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > Cc: Sean Paul <sean@xxxxxxxxxx> > Cc: Brian Starkey <Brian.Starkey@xxxxxxx> > Cc: Eric Anholt <eric@xxxxxxxxxx> > Cc: Stéphane Marchesin <marcheu@xxxxxxxxxxxx> > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > Signed-off-by: Matt Roper <matthew.d.roper@xxxxxxxxx> > Reviewed-by(v2): Sean Paul <sean@xxxxxxxxxx> _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
