linux-kernel - Re: [PATCH v10 6/6] arm64: defconfig: Enable Synopsys HDMI receiver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <863f9c1beb7a912f94f8740b3e5095e09e49cee5.camel@collabora.com>
Date: Thu, 27 Feb 2025 22:51:37 -0500
From: Nicolas Dufresne <nicolas.dufresne@...labora.com>
To: Hans Verkuil <hverkuil@...all.nl>, Dmitry Osipenko	
 <dmitry.osipenko@...labora.com>, Shreeya Patel
 <shreeya.patel@...labora.com>,  Heiko Stuebner	 <heiko@...ech.de>, Mauro
 Carvalho Chehab <mchehab@...nel.org>, Rob Herring	 <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley	
 <conor+dt@...nel.org>, jose.abreu@...opsys.com, nelson.costa@...opsys.com, 
	shawn.wen@...k-chips.com, Sebastian Reichel
 <sebastian.reichel@...labora.com>
Cc: kernel@...labora.com, linux-media@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-rockchip@...ts.infradead.org, Tim Surber <me@...surber.de>,
 Christophe JAILLET <christophe.jaillet@...adoo.fr>
Subject: Re: [PATCH v10 6/6] arm64: defconfig: Enable Synopsys HDMI receiver

Hi Hans,

Le mercredi 26 février 2025 à 09:31 +0100, Hans Verkuil a écrit :
> On 25/02/2025 19:30, Dmitry Osipenko wrote:
> > From: Sebastian Reichel <sebastian.reichel@...labora.com>
> > 
> > The Rockchip RK3588 has a built-in HDMI receiver block from
> > Synopsys. Let's enable the driver for it.
> > 
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@...labora.com>
> > Signed-off-by: Dmitry Osipenko <dmitry.osipenko@...labora.com>
> > ---
> >  arch/arm64/configs/defconfig | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/arch/arm64/configs/defconfig
> > b/arch/arm64/configs/defconfig
> > index cb7da4415599..3dccc9e1c4aa 100644
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -859,6 +859,8 @@ CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC=m
> >  CONFIG_VIDEO_SAMSUNG_S5P_JPEG=m
> >  CONFIG_VIDEO_SAMSUNG_S5P_MFC=m
> >  CONFIG_VIDEO_SUN6I_CSI=m
> > +CONFIG_VIDEO_SYNOPSYS_HDMIRX=m
> > +CONFIG_VIDEO_SYNOPSYS_HDMIRX_LOAD_DEFAULT_EDID=y
> 
> I do not believe it is a good idea to default to y for this option.
> 
> The EDID depends on the specific device you make, and you should
> think carefully about whether the default EDID fits the needs of the
> device.
> 
> So if you want the default EDID, then you should manually select it
> and not have it autoselected.

Following up here, from the device maker perspective sure, but I'm not
sure this is the best choice for generic Linux distribution. As of
today, pretty much no userspace capture software knows about this,
meaning the device will not work out of the box in OBS, GStreamer,
Ffmpeg, Web Browsers. In comparison, if you pick any UVC HDMI capture,
it just work, with a default EDID that covers the range of
capabilities, which in this case are defined by the SoC.

Whatever we make as a choice, will always be the wrong choice for
someone, though I expect this to be a lot easier to change for
"specialized" implementation. Now, since there is no reason you can't
do a specilized implementation on generic Linux distro, and because you
might disagree with me, perhaps a compromise is to also add a module
parameter, so that there is a run-time override to this.

Nicolas

> 
> Regards,
> 
> 	Hans
> 
> >  CONFIG_VIDEO_TI_J721E_CSI2RX=m
> >  CONFIG_VIDEO_HANTRO=m
> >  CONFIG_VIDEO_IMX219=m
> 
> 

-- 
Nicolas Dufresne
Principal Engineer at Collabora