Re: [PATCH v9 14/27] drm/connector: hdmi: Compute bpc and format automatically

[Ville Syrjälä]

On Mon, Mar 18, 2024 at 01:05:22PM +0100, Maxime Ripard wrote:
> Hi Ville,
> 
> Thanks for your review !
> 
> On Fri, Mar 15, 2024 at 10:05:16AM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 11, 2024 at 03:49:42PM +0100, Maxime Ripard wrote:
> > > +static bool
> > > +sink_supports_format_bpc(const struct drm_connector *connector,
> > > +			 const struct drm_display_info *info,
> > > +			 const struct drm_display_mode *mode,
> > > +			 unsigned int format, unsigned int bpc)
> > > +{
> > > +	struct drm_device *dev = connector->dev;
> > > +	u8 vic = drm_match_cea_mode(mode);
> > > +
> > > +	if (vic == 1 && bpc != 8) {
> > > +		drm_dbg(dev, "VIC1 requires a bpc of 8, got %u\n", bpc);
> > 
> > Use of drm_dbg() for kms stuff is surprising.
> > 
> > > +		return false;
> > > +	}
> > 
> > I don't think we have this in i915. My original impression was that you
> > can use higher color depth if you can determine the sink capabilities,
> > but all sinks are required to accept 640x480@8bpc as a fallback.
> > 
> > but CTA-861-H says:
> > "5.4 Color Coding & Quantization
> >  Component Depth: The coding shall be N-bit, where N = 8, 10, 12, or 16
> >  bits/component — except in the case of the default 640x480 Video Timing 1,
> >  where the value of N shall be 8."
> > 
> > So that does seem to imply that you're supposed to use exactly 8bpc.
> > Though the word "default" in there is confusing. Are they specifically
> > using that to indicate that this is about the fallback behaviour, or
> > is it just indicating that it is a "default mode that always has to
> > be supported". Dunno. I guess no real harm in forcing 8bpc for 640x480
> > since no one is likely to use that for any high fidelity stuff.
> 
> My understanding was that CTA-861 mandates that 640x480@60Hz is
> supported, and mentions it being the default timing on a few occurences,
> like in section 4 - Video Formats and Waveform Timings that states "This
> section describes the default IT 640x480 Video Timing as well as all of
> the standard CE Video Timings.", or Section 6.2 - Describing Video
> Formats in EDID "The 640x480@60Hz flag, in the Established Timings area,
> shall always be set, since the 640x480p format is a mandatory default
> timing."
> 
> So my understanding is that default here applies to the timing itself,
> and not the bpc, and is thus the second interpretation you suggested.
> 
> I'll add a comment to make it clearer.
> 
> > > +static int
> > > +hdmi_compute_format(const struct drm_connector *connector,
> > > +		    struct drm_connector_state *state,
> > > +		    const struct drm_display_mode *mode,
> > > +		    unsigned int bpc)
> > > +{
> > > +	struct drm_device *dev = connector->dev;
> > > +
> > > +	if (hdmi_try_format_bpc(connector, state, mode, bpc, HDMI_COLORSPACE_RGB)) {
> > > +		state->hdmi.output_format = HDMI_COLORSPACE_RGB;
> > > +		return 0;
> > > +	}
> > > +
> > > +	if (hdmi_try_format_bpc(connector, state, mode, bpc, HDMI_COLORSPACE_YUV422)) {
> > > +		state->hdmi.output_format = HDMI_COLORSPACE_YUV422;
> > > +		return 0;
> > > +	}
> > 
> > Looks like you're preferring YCbCr 4:2:2 over RGB 8bpc. Not sure
> > if that's a good tradeoff to make.
> 
> Yeah, indeed. I guess it's a judgement call on whether we prioritise
> lowering the bpc over selecting YUV422, but I guess I can try all
> available RGB bpc before falling back to YUV422.
> 
> > In i915 we don't currently expose 4:2:2 at all because it doesn't
> > help in getting a working display, and we have no uapi for the
> > user to force it if they really want 4:2:2 over RGB.
> 
> I guess if the priority is given to lowering bpc, then it indeed doesn't
> make sense to support YUV422, since the limiting factor is likely to be
> the TMDS char rate and YUV422 12 bpc is equivalent to RGB 8bpc there.
> 
> dw-hdmi on the other hand will always put YUV422 and YUV444 before RGB
> for a given bpc, which is weird to me:
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2696
> 
> What is even weirder to me is that YUV422 is explicitly stated to be
> 12bpc only, so there's some invalid configurations there (8 and 10 bpc).
> 
> And given that it's order by decreasing order of preference, I'm pretty
> sure it'll never actually pick any YUV or RGB > 8bpc format since RGB
> 8bpc is super likely to be always available and thus picked first.

8bpc RGB is in fact mandatory.

> 
> If we want to converge, I think we should amend this code to support
> YUV420 for YUV420-only modes first, and then the RGB options like i915
> is doing. And then if someone is interested in more, we can always
> expand it to other formats.
> 
> > > +
> > > +	drm_dbg(dev, "Failed. No Format Supported for that bpc count.\n");
> > > +
> > > +	return -EINVAL;
> > > +}
> > > +
> > > +static int
> > > +hdmi_compute_config(const struct drm_connector *connector,
> > > +		    struct drm_connector_state *state,
> > > +		    const struct drm_display_mode *mode)
> > > +{
> > > +	struct drm_device *dev = connector->dev;
> > > +	unsigned int max_bpc = clamp_t(unsigned int,
> > > +				       state->max_bpc,
> > > +				       8, connector->max_bpc);
> > > +	unsigned int bpc;
> > > +	int ret;
> > > +
> > > +	for (bpc = max_bpc; bpc >= 8; bpc -= 2) {
> > > +		drm_dbg(dev, "Trying with a %d bpc output\n", bpc);
> > > +
> > > +		ret = hdmi_compute_format(connector, state, mode, bpc);
> > 
> > Hmm. Actually I'm not sure your 4:2:2 stuff even works since you 
> > check for bpc==12 in there and only call this based on the max_bpc.
> > I'm not convinced max_bpc would actually be 12 for a sink that
> > supports YCbCr 4:2:2 but not 12bpc RGB.
> 
> It's another discussion we had in an earlier version, but yeah we lack
> the infrastructure to support those for now. I still believe it would
> require an increased max_bpc to select YUV422, otherwise things would be
> pretty inconsistent with other YUV formats.

Ideally I'd like to know the actual color depth of the panel
independently of the supported signal color depths. Unfortunately
I don't think EDID gives us that. Can't recall if DisplayID might
have something a bit more sensible.

Given how info->bpc works right now, I suppose it would make sense
to bump it up to 12 when 4:2:2 is supported. But I've not thought
through the actual implications such a change.

> But yeah, we need to provide a hook to report we don't support RGB >
> 8bpc for HDMI 1.4 devices. Which goes back to the previous question
> actually, I believe it would still provide value to support YUV422 on
> those devices, with something like:
> 
> for (bpc = max_bpc; bpc >= 8; bpc -= 2) {
>     if (!connector->hdmi->funcs->validate_config(mode, RGB, bpc))
>        continue;
> 
>     // Select RGB with bpc
>     ...
> }
> 
> if (connector->hdmi->funcs->validate_config(mode, YUV) &&
>     hdmi_try_format_bpc(..., mode, 12, YUV422) {
>    // Select YUV422, 12 bpc
>    ...
> }
> 
> What do you think?

Since 8bpc RGB must always be supported this looks
like dead code to me.

-- 
Ville Syrjälä
Intel