Re: [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Christoph Manszewski <c.manszewski@samsung.com>,
	intel-gfx@lists.freedesktop.org,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	dri-devel@lists.freedesktop.org
Subject: Re: [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane
Date: Fri, 30 Nov 2018 17:16:57 +0200	[thread overview]
Message-ID: <20181130151657.GY9144@intel.com> (raw)
In-Reply-To: <8b72c23b-57ea-bc3b-9f26-2552e5477915@xs4all.nl>

On Fri, Nov 30, 2018 at 03:48:00PM +0100, Hans Verkuil wrote:
> On 11/30/18 15:29, Ville Syrjälä wrote:
> > On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote:
> >> Hi Ville,
> >>
> >> As Christoph cannot respond till middle next week I can try to respond
> >> in his absence, as I am familiar with the subject.
> >>
> >> On 30.11.2018 14:25, Ville Syrjälä wrote:
> >>> On Fri, Nov 30, 2018 at 02:08:11PM +0100, Christoph Manszewski wrote:
> >>>> Hi,
> >>>>
> >>>> I am looking for a way to export the color encoding and range selection
> >>>> to user space. I came across those properties and am wondering, why
> >>>> they are meant only for non RGB color encodings. Would it be okay, to
> >>>> modify them and use with RGB formats as well?
> >>> What you trying to do? Input limited range RGB data and expand to full
> >>> range?
> >>
> >>
> >> For example. But there are two more general questions, which
> >> surprisingly we have not found answer for.
> >>
> >> 1. What color encoding and range drm should expect on its input RGB
> >> buffers by default?
> > 
> > RGB is just RGB. There is no encoding. It's assumed to be full range
> > because no one really uses anything else.
> 
> For simple desktop usage that's true. When dealing with video inputs,
> this becomes much more complicated.
> 
> > 
> >>
> >> 2. How userspace should inform drm that given buffer has specified
> >> non-default color encoding and range?
> >>
> >>
> >> Hopefully this patch introduces such properties but only for YCbCr
> >> formats, the question is what should be the best way to expand it to RGB
> >> formats:
> >>
> >> A. Add another enums: DRM_COLOR_RGB_BT601 and friends.
> > 
> > BT.601 specifies how to encoder RGB data as YCbCr. So without
> > YCbCr BT.601 does not mean anything. Well, the standard does
> > contain other things as well I suppose, but for the purposes
> > of the color encoding prop only that one part is relevant.
> 
> Ah, I misunderstood the meaning of DRM_COLOR_RGB_BT601.
> This is the equivalent of V4L2_YCBCR_ENC_601, and that's indeed
> only defined for Y'CbCr. But it is often (ab)used as an alias for
> the SMPTE170M colorspace (used by SDTV).
> 
> V4L2 has the following defines for colorspaces, transfer functions,
> Y'CbCr (and HSV) encodings and quantization ranges:
> 
> https://hverkuil.home.xs4all.nl/spec/uapi/v4l/colorspaces-defs.html

Yeah, we're going to be introducing other properties to control
colorspace and transfer function in kms as well. Actually some
patches towards that have been floated a few times already.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel