Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
MIME-Version: 1.0
References: <20221207-rpi-hdmi-improvements-v3-0-bdd54f66884e@cerno.tech>
 <20221207-rpi-hdmi-improvements-v3-3-bdd54f66884e@cerno.tech>
 <CAKMK7uFQ8yJLKgTrQdmhwmq9uL-hbUsfUeU6cxWdB2AW3i4vOg@mail.gmail.com>
 <fwcn3vlgxq5uygi32pyjuktj62wa7zvdgu7xxlpqr7an3kjn7i@25axhlrrkk6z>
 <12669999-295f-40c5-8c58-ba3ed26efb16@xs4all.nl> <tnkfcgkoobxyyhnsmoyayohip73wl6axnd7liefsvof6qwgovd@ropob4set3nl>
In-Reply-To: <tnkfcgkoobxyyhnsmoyayohip73wl6axnd7liefsvof6qwgovd@ropob4set3nl>
From:   Sebastian Wick <sebastian.wick@redhat.com>
Date:   Mon, 23 Oct 2023 18:22:27 +0200
Message-ID: <CA+hFU4yeUsGy9rzq3H6hmfkjXsYHxf6W=bJ-1ti1Um9jgkihcQ@mail.gmail.com>
Subject: Re: [PATCH v3 3/9] drm/vc4: hdmi: Add Broadcast RGB property to allow
 override of RGB range
To:     Maxime Ripard <maxime@cerno.tech>
Cc:     Hans Verkuil <hverkuil@xs4all.nl>, Emma Anholt <emma@anholt.net>,
        Dave Stevenson <dave.stevenson@raspberrypi.com>,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Honestly, the less time people spend on this property the better. Lift
the Intel one into core and be done with it. We'll hopefully be able
to remove it in the not-to-distant future with the new color pipeline
API and adding a new property which only sets the connector metadata
instead of influencing the color pipeline as well.

On Mon, Oct 23, 2023 at 4:58=E2=80=AFPM Maxime Ripard <maxime@cerno.tech> w=
rote:
>
> Hi Hans,
>
> On Thu, Oct 19, 2023 at 10:26:40AM +0200, Hans Verkuil wrote:
> > Hi Maxime,
> >
> > On 19/10/2023 10:02, Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Wed, Oct 11, 2023 at 03:23:18PM +0200, Daniel Vetter wrote:
> > >> On Mon, 6 Mar 2023 at 11:49, Maxime Ripard <maxime@cerno.tech> wrote=
:
> > >>>
> > >>> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
> > >>>
> > >>> Copy Intel's "Broadcast RGB" property semantics to add manual overr=
ide
> > >>> of the HDMI pixel range for monitors that don't abide by the conten=
t
> > >>> of the AVI Infoframe.
> > >>>
> > >>> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> > >>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > >>
> > >> Stumbled over this grepping around, but would have been nice to lift
> > >> this into drm code and document the property. It's one of the legacy
> > >> ones from the table of horrors after all ...
> > >>
> > >> Shouldn't be an uapi problem because it's copypasted to much, just n=
ot great.
> > >
> > > We already discussed it on IRC, but just for the record I have a curr=
ent
> > > series that should address exactly that:
> > >
> > > https://lore.kernel.org/dri-devel/20230920-kms-hdmi-connector-state-v=
2-3-17932daddd7d@kernel.org/
> > >
> > > Maxime
> >
> > I've pasted a snippet from that patch below for a quick review:
> >
> > >  /**
> > >   * DOC: HDMI connector properties
> > >   *
> > > + * Broadcast RGB (HDMI Specific):
> >
> > Full vs Limited is actually not HDMI specific, DisplayPort can signal t=
his as
> > well for whatever it is worth.
>
> Sure, what I (and the original patch I guess) meant is that it's only
> ever used on HDMI connectors these days. If that ever changes, then we
> can update the doc.
>
> > > + *      Indicates the RGB Range (Full vs Limited) used.
> >
> > RGB Range -> RGB Quantization Range
> >
> > > + *
> > > + *      The value of this property can be one of the following:
> > > + *
> > > + *      Automatic:
> > > + *              RGB Range is selected automatically based on the mod=
e
> > > + *              according to the HDMI specifications.
> > > + *
> > > + *      Full:
> > > + *              Full RGB Range is forced.
> > > + *
> > > + *      Limited 16:235:
> >
> > It is very unfortunate that this is called "Limited 16:235" instead of =
just "Limited"
> > since for color component bit depths > 8 these values are different.
> >
> > I have no idea if it is possible to add an alias "Limited" that you can=
 use instead.
> > In any case, this should document that it works just as well for higher=
 bit depths,
> > but with different limits.
>
> I had a look and it doesn't look like the property infrastructure can
> deal with aliases. I'll add something in the doc
>
> Thanks!
> Maxime