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.rip...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
