linux-kernel - Re: [PATCH 2/4] drm/bridge: dw-hdmi: Fix color space conversion detection

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4602894.0VBMTVartN@jernej-laptop>
Date:   Mon, 02 Mar 2020 13:45:44 +0100
From:   Jernej Škrabec <jernej.skrabec@...l.net>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     a.hajda@...sung.com, narmstrong@...libre.com, jonas@...boo.se,
        airlied@...ux.ie, daniel@...ll.ch, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] drm/bridge: dw-hdmi: Fix color space conversion detection

Dne ponedeljek, 02. marec 2020 ob 10:27:48 CET je Laurent Pinchart napisal(a):
> Hi Jernej,
> 
> Thank you for the patch.
> 
> On Sat, Feb 29, 2020 at 05:30:41PM +0100, Jernej Skrabec wrote:
> > Currently, is_color_space_conversion() compares not only color spaces
> > but also formats. For example, function would return true if YCbCr 4:4:4
> > and YCbCr 4:2:2 would be set. Obviously in that case color spaces are
> > the same.
> > 
> > Fix that by comparing if both values represent RGB color space.
> > 
> > Fixes: b21f4b658df8 ("drm: imx: imx-hdmi: move imx-hdmi to
> > bridge/dw_hdmi")
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@...l.net>
> 
> This isn't implemented today, but could the CSC be used to convert
> between different YCbCr encodings ?

Yes, CSC offers great flexibility, but unfortunately that also means that you 
have as much CSC matrices as there is possible conversions. This explodes 
quickly, especially if you convert from one YCbCr encoding to another (BT.601, 
BT.709, BT.2020) and also considering range (full, limited). If you don't mind 
doing some calculations in code, this becames much simpler, but doing fixed 
point arithmetic isn't fun. Is floating point arithmetic allowed in kernel?

I wrote a simple program to produce all those CSC matrices for sun4i-drm 
driver: http://ix.io/2dak Note that it's for RGB <-> YUV conversion, but DW 
HDMI has a bit different order. I believe it's GRB, but I'm not 100% sure.

You can also do various color adjustements, like brigthness, but that would 
also mean that you have to multiply all matrices to get final one which you can 
then write into registers.

Best regards,
Jernej

> 
> In any case the patch is correct based on the current implementation, so
> 
> Reviewed-by: Laurent Pinchart <laurent.pinchart@...asonboard.com>
> 
> > ---
> > 
> >  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > 24965e53d351..9d7bfb1cb213 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -956,7 +956,8 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
> > 
> >  static int is_color_space_conversion(struct dw_hdmi *hdmi)
> >  {
> > 
> > -	return hdmi->hdmi_data.enc_in_bus_format !=
> > hdmi->hdmi_data.enc_out_bus_format; +	return
> > hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_in_bus_format) !=
> > +		hdmi_bus_fmt_is_rgb(hdmi-
>hdmi_data.enc_out_bus_format);
> > 
> >  }
> >  
> >  static int is_color_space_decimation(struct dw_hdmi *hdmi)