lkml.org 
[lkml]   [2017]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB
    From
    Date
    Hi Ville,


    On 10-01-2017 17:21, Ville Syrjälä wrote:

    [snip]

    >> But we already have color_formats field in drm_display_info
    >> struct, right? Shouldn't we instead create for example a helper
    >> which returns the best output colorspace? According to what you
    >> said it would be something like:
    >>
    >> if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
    >> return YCBCR444;
    >> else if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
    >> return YCBCR422;
    >> else if (display_info->color_formats & DRM_COLOR_FORMAT_YCBCR420
    >> && vic_is_420)
    >> return YCBCR420;
    >> else
    >> return RGB444; /* Mandatory by spec */
    > Perhaps. But it would have to be more involved than that since there
    > might limitations on eg. the max TMDS clock imposed by the source or
    > cable/dongle which presumably might require that we pick 4:2:0 over
    > 4:4:4.
    >
    > It would also need to account which formats are actually supported by
    > the source.
    >
    > I guess for bpc it would be enough to just consider 8bpc in such a
    > function, and then the driver can bump it up afterwards if possible.

    But the max tmds clock will probably be involved in deep color
    modes, as 24bpp has always a 1x factor in every YCbCr, except
    4:2:0. So, the sink has a max tmds but this gets into account
    when the vic list present in the EDID is built, but not
    considered in deep color modes, unless the EDID is broken.

    >
    > As for the RGB vs. YCbCr question, I guess we should just prefer RGB444
    > for now. And fall back to YCbCr 4:2:2 or 4:2:0 if necessary. And that
    > leaves YCbCr 4:4:4 unsed since it has the same requirements as RGB
    > 4:4:4 and thus doesn't provide any benefit as such. We could later add
    > a property to let the user choose between RGB vs. YCbCr more explicitly.
    >

    Hmm, I am trying to implement this but I am facing a difficulty:
    how will I fallback to YCbCr? RGB is always supported and the max
    tmds only enters in deep color modes. For reference here is a
    simple struct i created with the different tmds character rate
    factors for the different encodings (I think they are correct,
    but cross check please):

    #define DRM_CS_DESC(cs, f, b) \
    .colorspace = (cs), .factor_to_khz = (f), .bpc = (b)

    static const struct drm_mode_colorspace_desc {
    u32 colorspace;
    u32 factor_to_khz;
    u32 bpc;
    } drm_mode_colorspace_factors = { /* Ordered by descending
    preference */
    { DRM_CS_DESC(DRM_COLOR_FORMAT_RGB444, 2000, 48) },
    { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB444, 2000, 48) },
    { DRM_CS_DESC(DRM_COLOR_FORMAT_RGB444, 1500, 36) },
    { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB444, 1500, 36) },
    { DRM_CS_DESC(DRM_COLOR_FORMAT_RGB444, 1250, 30) },
    { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB444, 1250, 30) },
    { DRM_CS_DESC(DRM_COLOR_FORMAT_RGB444, 1000, 24) },
    { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB444, 1000, 24) },
    { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB422, 1000, 24) },
    { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB422, 1000, 30) },
    { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB422, 1000, 36) },
    { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB420, 1000, 48) },
    { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB420, 750, 36) },
    { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB420, 625, 30) },
    { DRM_CS_DESC(DRM_COLOR_FORMAT_YCRCB420, 500, 24) },

    Notice how YCbCr 4:4:4 will never get picked: it has the same
    factor of RGB 4:4:4 for every bpc. So, the sink must support RGB
    4:4:4 and may support YCbCr. What I didn't check was that if it
    is possible to have support for deep color YCbCr without having
    support for deep color RGB 4:4:4. Do you know if this can happen?

    Best regards,
    Jose Miguel Abreu

    \
     
     \ /
      Last update: 2017-01-11 11:28    [W:2.704 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site