Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB

[Ville Syrjälä]

On Tue, Jan 10, 2017 at 05:01:08PM +0000, Jose Abreu wrote:
> Hi Ville,
> 
> 
> [snip]
> 
> >> Are you going to update all the userspace clients? Exposing HDMI 2.0
> >> modes only for your favorite client doesn't sound like a good plan to
> >> me.
> >>
> >> If we simply compute from a specific modeline whether it needs to be
> >> transmitted as 4:2:0, I suppose we could simply look for a matching
> >> mode in the 4:2:0 mode. But that would mean that only the exact modes
> >> listed by the EDID will work, and others might not.
> > OK, so the 4:2:0 support is apparently listed only for specific VICs.
> 
> Hmm, the spec is not very clear. It lists video timings which may
> be used with YCbCr 4:2:0 but does not explicitly say that only
> these timings can be used. Anyway, I checked with a colleague who
> has direct access to HDMI Forum and indeed only VIC 96, 97, 101,
> 102, 106 and 107 can be used with 4:2:0, so you are correct. He
> said that the initial intention of this pixel encoding was to
> give 60Hz refresh rate in 4k to users who had limited
> performance, so it was only intended for higher resolutions.
> 
> > Hence we will need to just go through those lists to see if we can
> > (or in fact must) use 4:2:0 for a specific user specified mode.
> 
> We don't have yet support for these VICs, so this will have to
> wait :(
> 
> >
> > I would say the only slight question mark at this point is whether we
> > should favor 4:4:4 at lower bpc or 4:2:0 at higher bpc if we can choose
> > between the two. My first instinct is to favor the 4:4:4 modes for now.
> > We could add some knobs later to let the user make that choice.
> 
> I agree that 4:4:4 should be preferred.
> 
> [snip]
> 
> >>> Ok. But note that there is no nice way to figure this out. For
> >>> example, for a graphics card it all depends (apart from the
> >>> graphics HW) on the PCIe bus. If the bus is not free for enough
> >>> data rate then user can reach bottlenecks and not output at best
> >>> performance. If we gave user the ability to switch from, for
> >>> example, RGB to YCbCr 4:2:0 this bottleneck could be eliminated.
> >> Userspace won't know anything about such bottlenecks. The kernel
> >> can know it and hence should automagically drop into 4:2:0 mode
> >> if necessary.
> >>
> >>> Unless of course we always prefer YCbCr 4:2:0, when possible. I
> >>> did this internally for bridge driver dw-hdmi. We always prefer
> >>> YCbCr over RGB when they are available. It is user transparent as
> >>> the controller does the necessary color space conversion, though,
> >>> not ideal in my opinion.
> >> My idea was that we'd have a property for the output colorspace and
> >> would perhaps default to YCbCr for the CEA modes (as per CEA-861).
> >> Though I'm sure some people would cry about that behaviour as well.
> >> But for the cases where there is no choice but to use a specific
> >> output colorspace, the kernel should just do it automagically IMO. No
> >> point in manking life diffcult for userspace.
> 
> 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.

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.

-- 
Ville Syrjälä
Intel OTC