Hi, On Fri, Nov 30, 2018 at 04:34:54PM +0100, Hans Verkuil wrote: > On 11/30/18 16:16, Ville Syrjälä wrote: > > 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? This is where I personally think we've got an unfortunate disconnect in the KMS UAPI. For YCbCr buffers, these properties specify the encoding and range of the data in the buffer. But everything else in the pipe is described in terms of the processing to apply - i.e. the KMS driver doesn't know what transfer function the data uses, it only knows the degamma LUT it's told to apply to it. It would have been more uniform if the COLOR_ENCODING/COLOR_RANGE properties were a single "ENCODING_CONVERSION" property stating what conversion should be applied. > >>> > >>> 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. > >> When the plane degamma/ctm/gamma properties land, those could be used to convert limited range to whatever the pipe-internal format is, I think. That pipe-internal format would be whatever userspace decides it is, via converting input buffers using the various color conversion properties. > >>> > >>>> > >>>> 2. How userspace should inform drm that given buffer has specified > >>>> non-default color encoding and range? > >>>> My understanding is that DRM would never be informed of this - only what to do with the data (which does of-course imply an encoding, but it's not told to DRM explicitly). > >>>> > >>>> 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. > > > > Great. Let's try to keep drm and V4L2 in sync for this. It should be > possible to convert from one to the other without having to do weird > things. > > I'll try to pay attention to these patches, but just ping me if you > want me to take a look at something. > > I put a lot of effort into the V4L2 colorspace documentation, trying to > put all the information in one place, esp. all the formulas. There's always going to be a bit of a disconnect here - in KMS, it's userspace which needs to handle all this stuff. It would be up to userspace to set e.g. DEGAMMA_LUT to a LUT which corresponds to SMPTE 2084, rather than the kernel driver being told directly that the buffer is encoded using the SMPTE 2084 transfer function. Actually I want to put an RFC together to allow DEGAMMA_LUT/GAMMA_LUT to be set to some pre-defined values (e.g. sRGB, PQ, HLG) to suit hardware which has built-in hard-coded transfer functions (and potentially also save userspace some effort of coming up with LUTs). Cheers, -Brian > > Regards, > > Hans > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
