[PATCH 2/7] drm/edid: Allow to ignore the audio EDID data

[Ville Syrjälä]

On Mon, Mar 04, 2019 at 03:52:35PM +0100, Maxime Ripard wrote:
> In some cases, in order to accomodate with displays with poor EDIDs, we
> need to ignore that the monitor alledgedly supports audio output and
> disable the audio output.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at bootlin.com>
> ---
>  drivers/gpu/drm/drm_edid.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 990b1909f9d7..c0258b011bb2 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4190,6 +4190,11 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
>  }
>  EXPORT_SYMBOL(drm_detect_hdmi_monitor);
>  
> +static bool ignore_edid_audio = false;
> +module_param(ignore_edid_audio, bool, 0644);
> +MODULE_PARM_DESC(ignore_edid_audio,
> +		 "Ignore the EDID and always consider that a monitor doesn't have audio capabilities");
> +

I would suggest that this is not the best apporach. Years of experience
from i915 says that more modparams means random forums full of people
trading  cargo culted settings. And as soon as the average user comes
across the magic incantation that works they are likely to not file the
appropriate bug report. Also years later we still see people using
modparams that stopped working five hardware generations ago. So at
least for i915 new modparams are generally frowned upon.

Bad EDIDs at least should be quirked. Which means we really need the
bug reports, and hence a modparam can be somewhat counter productive.

For allowing the user to force the DVI vs. HDMI and audio vs. not i915
does have the "audio" connector property. Other drivers could adopt the
same thing. Though I'm not sure even i915 should be exposing this for
the reasons already mentioned. There is one hardware generation where
it can actually be useful on i915 as the hardware is only capably of
sending infoframes/audio to a single HDMI port at a time. So with this
property the user can at least select which display gets to do those
things.

I do agree that there is an unfortnate problem with fbcon vs.
initial property values. I've sometimes pondered about exposing
kms properties in a generic fashion via sysfs and/or kernel
cmdline somehow. IIRC devicetree/something similar has also been
proposed occasionally to solve this problem.

>  /**
>   * drm_detect_monitor_audio - check monitor audio capability
>   * @edid: EDID block to scan
> @@ -4209,6 +4214,9 @@ bool drm_detect_monitor_audio(struct edid *edid)
>  	bool has_audio = false;
>  	int start_offset, end_offset;
>  
> +	if (ignore_edid_audio)
> +		goto end;
> +
>  	edid_ext = drm_find_cea_extension(edid);
>  	if (!edid_ext)
>  		goto end;
> -- 
> git-series 0.9.1
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel