On 03/03/2017 05:39 PM, Jose Abreu wrote: > Hi Neil, > > > On 03-03-2017 11:31, Neil Armstrong wrote: >> >> Sure, but I was struggling about finding an equivalence. >> >> How should I replace these ? >> >> DW_HDMI_ENC_FMT_RGB >> DW_HDMI_ENC_FMT_YCBCR444 >> DW_HDMI_ENC_FMT_YCBCR422_16BITS >> DW_HDMI_ENC_FMT_YCBCR422_8BITS >> DW_HDMI_ENC_FMT_XVYCC444 >> >> I do not have the strict information about the bus format, what is RGB in 8bit per pixel ? >> Are the 3 samples transmitted separately ? >> What should be the RGB colorspace ? >> Should we use the "Packed" formats, LVDS or a new buf format ? >> >> Jose, what are the *exact* bus formats supported ? > > Well, the controller supports everything that is in the HDMI spec > (1.4 and 2.0), the implementation is the one that limits the > supported formats. There is also a CSC but it does not convert > from anything to everything :) Sure, I was meaning the *input* format the controller receives from the pixel encoder, I'm quite sure the format is strict. > > I think you can safely add every MBUS code that is compatible > with HDMI. Namely: > - 24/30/36/48-bit RGB 4:4:4 > - 24/30/36/48-bit YCbCr 4:4:4 > - 16/20/24-bit YCbCr 4:2:2 > - 24/30/36/48-bit YCbCr 4:2:0 > > And then let the glue drivers decide which they support in input > and what they want in output (the output is a little tricky > because it will depend in EDID, this should be handled by > userspace + drm core and not the drivers so let it fixed to RGB, > just in case). > >> >> Same for DW_HDMI_ENC_FMT_YCBCR* stuff, are they packed ? > > Hmm, this depends on the implementation. The controller always > receives 48bits of data per pixel, its the implementation that is > responsible to correctly align that data. > >> >> I understand the YCBCR444/XVYCC444 needs a color space information instead. >> >> Could we use the following list ? >> >> Bus Format | Colorspace | Encoding >> ------------------------------------------------------------------------------- >> MEDIA_BUS_FMT_RGB888_1X24 | V4L2_COLORSPACE_SRGB | V4L2_XFER_FUNC_SRGB >> MEDIA_BUS_FMT_RGB101010_1X30 | V4L2_COLORSPACE_SRGB | V4L2_XFER_FUNC_SRGB >> MEDIA_BUS_FMT_RGB121212_1X36 | V4L2_COLORSPACE_SRGB | V4L2_XFER_FUNC_SRGB >> MEDIA_BUS_FMT_VUY8_1X24 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_709 >> MEDIA_BUS_FMT_YUV10_1X30 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_709 >> MEDIA_BUS_FMT_YUV10_1X32 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_709 >> MEDIA_BUS_FMT_YUV10_1X32 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_709 >> MEDIA_BUS_FMT_YUV10_1X32 | V4L2_XFER_FUNC_709 | V4L2_YCBCR_ENC_XV709 > > I think the HDMI spec dictates the default colorspace+encoding > for each bus format, not sure though, Laurent? > > Best regards, > Jose Miguel Abreu > >> >> But all of these is complex, and I'm not sure how we should handle SDTV modes here, >> and without knowing the exact inputs types supported by the IP, this needs to be >> confirmed. >> >> Meanwhile, all this can be fixed later, at least this patch moves the >> definition out of the C file and uses better names for these custom enums. >> > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
