Re: The state of Quantization Range handling

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3216 bytes --]

On Thu, 17 Nov 2022 22:39:36 +0100
Sebastian Wick <sebastian.wick@redhat.com> wrote:

> On Wed, Nov 16, 2022 at 1:34 PM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > Is it a good idea to put even more automation/magic into configuring
> > the color pipeline and metadata for a sink, making them even more
> > intertwined?
> >
> > I would prefer the opposite direction, making thing more explicit and
> > orthogonal.  
> 
> In general I completely agree with this, I just don't think it's
> feasible with the current state of KMS. For the color pipeline API [1]
> that's exactly the behavior I want but it should be guarded behind a
> DRM cap.
> 
> For that new API, user space needs direct control over the
> quantization range infoframe and the kernel has to somehow tell user
> space what quantization range the sink expects for the default
> behavior. User space then programs the infoframe when possible and
> builds the color pipeline in such a way that the output is whatever
> the sink expects.
> 
> The issue really is that if we push this all to user space it would be
> a backwards incompatible change. So let's fix the current situation in
> a backwards compatible way and then get it right for the new API that
> user space can opt-into.
> 
> Does that make sense?

It makes sense as far as userspace does not need to be changed to make
use of this.

But if userspace will need changes regardless, why continue on a
dead-end API? One reason could be that a new explicit API is too much
work compared to when you want your issues fixed.

If you are introducing a new KMS property (the override control), then
by definition userspace needs changes to use it.

[1] OTOH is a re-design the world -approach, which is am not suggesting
when I talk about making this explicit. I'm thinking about a much
smaller step that concerns only quantization range handling inside the
existing color pipeline "framework". E.g. deprecate "Broadcast RGB"
property and add "quantization range conversion" property that is
orthogonal to another new property for the quantization range metadata
sent to a sink.


Thanks,
pq

> > > Appendix A: Broadcast RGB property
> > >
> > > A few drivers already implement the Broadcast RGB property to control
> > > the quantization range. However, it is pointless: It can be set to
> > > Auto, Full and Limited when the sink supports explicitly setting the
> > > quantization range. The driver expects full range content and converts
> > > it to limited range content when necessary. Selecting limited range
> > > never makes any sense: the out-of-range bits can't be used because the
> > > input is full range. Selecting Default never makes sense: relying on
> > > the default quantization range is risky because sinks often get it
> > > wrong and as we established there is no reason to select limited range
> > > if not necessary. The limited and full options also are not suitable
> > > as an override because the property is not available if the sink does
> > > not support explicitly setting the quantization range.
> > >  
> >  
> 
> [1] https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/11
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]