Hi Ville, On Wednesday 30 Nov 2016 15:53:53 Ville Syrjälä wrote: > 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: > >>> 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. I don't think we need to expose the number of bits per component. If the colours are always expressed with 16 bits per component, the kernel can ignore the LSBs completely transparently for userspace. > 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)? It might be a theoretical issue though, as I'm not sure whether there's hardware out there that expresses the background colour in YUV. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
