linux-kernel - Re: [PATCH 1/6] include/drm: color

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: <20190118144424.GL20097@intel.com>
Date:   Fri, 18 Jan 2019 16:44:24 +0200
From:   Ville Syrjälä <ville.syrjala@...ux.intel.com>
To:     Andrzej Hajda <a.hajda@...sung.com>
Cc:     Christoph Manszewski <c.manszewski@...sung.com>,
        linux-samsung-soc@...r.kernel.org,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        Seung-Woo Kim <sw0312.kim@...sung.com>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        David Airlie <airlied@...ux.ie>,
        Kyungmin Park <kyungmin.park@...sung.com>,
        Kukjin Kim <kgene@...nel.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Sean Paul <sean@...rly.run>,
        linux-arm-kernel@...ts.infradead.org,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        'Hans Verkuil' <hans.verkuil@...co.com>
Subject: Re: [PATCH 1/6] include/drm: color_mgmt: Add enum labels

On Fri, Jan 18, 2019 at 03:34:18PM +0100, Andrzej Hajda wrote:
> +CC: Hans
> 
> On 17.01.2019 20:47, Ville Syrjälä wrote:
> > On Fri, Dec 14, 2018 at 01:10:16PM +0100, Christoph Manszewski wrote:
> >> Range setting makes sense for YCbCr and RGB buffers. Current
> >> drm_color_range enum labels suggest use with YCbCr buffers.
> >> Create enum labels without colorspace specification.
> >>
> >> Signed-off-by: Christoph Manszewski <c.manszewski@...sung.com>
> >> ---
> >>  include/drm/drm_color_mgmt.h | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> >> index 90ef9996d9a4..52f6d5221a0d 100644
> >> --- a/include/drm/drm_color_mgmt.h
> >> +++ b/include/drm/drm_color_mgmt.h
> >> @@ -62,6 +62,8 @@ enum drm_color_range {
> >>  	DRM_COLOR_YCBCR_LIMITED_RANGE,
> >>  	DRM_COLOR_YCBCR_FULL_RANGE,
> >>  	DRM_COLOR_RANGE_MAX,
> >> +	DRM_COLOR_LIMITED_RANGE = DRM_COLOR_YCBCR_LIMITED_RANGE,
> >> +	DRM_COLOR_FULL_RANGE = DRM_COLOR_YCBCR_FULL_RANGE,
> > These enum values don't mean anything really. The strings are what
> > matter for the uapi.
> >
> > The default for YCbCr needs to be limited range, the default for RGB
> > needs to be full range. So I think this would really require a separate
> > prop for each.
> >
> > But is there an actual usecase for this stuff?
> 
> 
> Yes, for example HDMI path (Display Controller and HDMI encoder) in
> Exynos5433 works on RGB buffers and do not perform any conversion if the
> output is also RGB, on the other side CEA861 specs says that in case of
> CEA modes output RGB should be in limited range, in case of non CEA
> modes it should be full range.
> 
> The idea was to allow userspace to check (atomic_check) which ranges are
> acceptable in given mode and to set desired one if possible.
> 
> Any better solution is welcome?

i915 has the "Broadcast RGB" property for the CEA-861 stuff.
You don't have a way to implement that?

-- 
Ville Syrjälä
Intel