linux-kernel - Re: [PATCH] drm/komeda: Adds output-color format/depth support

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]

Date:   Mon, 23 Sep 2019 15:50:59 +0300
From:   Ville Syrjälä <ville.syrjala@...ux.intel.com>
To:     Brian Starkey <Brian.Starkey@....com>
Cc:     "Lowry Li (Arm Technology China)" <Lowry.Li@....com>,
        nd <nd@....com>, Ayan Halder <Ayan.Halder@....com>,
        "airlied@...ux.ie" <airlied@...ux.ie>,
        Liviu Dudau <Liviu.Dudau@....com>,
        "Jonathan Chai (Arm Technology China)" <Jonathan.Chai@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "Julien Yin (Arm Technology China)" <Julien.Yin@....com>,
        "james qian wang (Arm Technology China)" <james.qian.wang@....com>,
        "seanpaul@...omium.org" <seanpaul@...omium.org>,
        Mihail Atanassov <Mihail.Atanassov@....com>
Subject: Re: [PATCH] drm/komeda: Adds output-color format/depth support

On Mon, Sep 23, 2019 at 12:16:12PM +0000, Brian Starkey wrote:
> Hi Lowry,
> 
> On Fri, Sep 20, 2019 at 09:43:47AM +0000, Lowry Li (Arm Technology China) wrote:
> > From: "Lowry Li (Arm Technology China)" <Lowry.Li@....com>
> > 
> > Sets color_depth according to connector->bpc.
> > Adds a new optional DT attribute "color-format" to represent a
> > preferred color formats for a specific pipeline, and the select order
> > is:
> > 	YCRCB420 > YCRCB422 > YCRCB444 > RGB444
> > The color-format can be anyone of these 4 format, one color-format not
> > only represent one format, but also include the lower formats, like
> > 
> > color-format         preferred_color_formats
> > YCRCB420        YCRCB420 > YCRCB422 > YCRCB444 > RGB444
> > YCRCB422        YCRCB422 > YCRCB444 > RGB444
> > YCRCB444        YCRCB444 > RGB444
> > RGB444          RGB444
> > 
> > Then the final color_format is calculated by 3 steps:
> > 1. calculate HW available formats.
> >   avail_formats = connector_color_formats & improc->color_formats;
> > 2. filter out un-preferred format.
> >   avail_formats &= preferred_color_formats;
> > 3. select the final format according to the preferred order.
> >   color_format = BIT(__fls(aval_formats));
> 
> Is there a specific use-case for the DT property for selecting color
> format?
> 
> I think in general the color format should be determined according to
> the rules in the CEA spec. There's also the drm_mode_is_420_only()
> helper we can use to determine if YCBCR420 must be used. For the cases
> where it's optional, I think we can default to RGB444.

That is the policy we have in i915. We have a vague plan to add
a new property for the user to select the encoding explicitly
(which would also allow things like YCbCr 4:4:4), but IIRC no
one has actually sent a patch for that.

CTA-861 sort of seems to say that one should favor YCbCr over
RGB iff both sides support it, but I think RGB is probably the
better default because it means straight passthrough (minus the
annoying full->limit quantization range trickery).

-- 
Ville Syrjälä
Intel