[PATCH 03/36] drm/omap: add crtc background property

[Ville Syrjälä]

On Wed, Nov 30, 2016 at 03:34:58PM +0200, Laurent Pinchart wrote:
> On Wednesday 30 Nov 2016 14:51:26 Tomi Valkeinen wrote:
> > On 30/11/16 13:25, Laurent Pinchart wrote:
> > > Hi Tomi,
> > > 
> > > Thank you for the patch.
> > > 
> > > On Wednesday 30 Nov 2016 13:17:05 Tomi Valkeinen wrote:
> > >> Add DRM property for crtc background color property. Background
> > >> color is shown on areas where there are no planes.
> > > 
> > > The background property is useful for the rcar-du driver as well, and I
> > > assume for a bunch of other display engines too. Could you please
> > > standardize it ? And for the usual bikeshedding required in those
> > > circumstances, should it be called background-color or bgcolor instead ?
> > 
> > The possible color values for background color property depend on the
> > HW. The current OMAP DSS has 8 bits per component, but other sizes
> > should be supported too.
> > 
> > I'm not sure how to implement that in a generic way... Always use 16
> > bits per component for the property?
> 
> That's one option. Another one would be to decide that 8 bit per component is 
> enough. The value of the background colour property could also possibly be 
> device-dependent, for instance if a device specifies it in YUV.

We have enough for 16 bits per component in u64. We can just throw away
the lsbs. I have already suggested that approach about a dozen times
throughout the years ;) We migth even have some i915 patches doing
that...

I don't have a very good idea for exposing the actual bpc though. Might
be doable with a parallel immutable mask property. But the big open
question is what happens if the actual bpc can change depending on the
crtc configuration. I would suggest we just ignore that issue for now.

For the RGB vs. YUV, we might just have separate props for those I
suppose. Although again it migth depend on the CRTC configuration
which one is effective. Maybe we need a separate "enable this bg color"
type of thing, which would then allow the driver to return an error if
the user is trying to set the wrong one? Or we could just have an enum
prop to select the format of the bg color property (RGB vs. YCbCr to
start with I guess). Yeah, I think I like that idea. And maybe we'd
need to expand that to include even more information about the actual
colorspace (eg. BT601 vs. BT709 vs. whatever for YCbCr)?

-- 
Ville Syrjälä
Intel OTC