The state of Quantization Range handling

The state of Quantization Range handling

[Sebastian Wick]

There are still regular bug reports about monitors (sinks) and sources
disagreeing about the quantization range of the pixel data. In
particular sources sending full range data when the sink expects
limited range. From a user space perspective, this is all hidden in
the kernel. We send full range data to the kernel and then hope it
does the right thing but as the bug reports show: some combinations of
displays and drivers result in problems.

In general the whole handling of the quantization range on linux is
not defined or documented at all. User space sends full range data
because that's what seems to work most of the time but technically
this is all undefined and user space can not fix those issues. Some
compositors have resorted to giving users the option to choose the
quantization range but this really should only be necessary for
straight up broken hardware.

Quantization Range can be explicitly controlled by AVI InfoFrame or
HDMI General Control Packets. This is the ideal case and when the
source uses them there is not a lot that can go wrong. Not all
displays support those explicit controls in which case the chosen
video format (IT, CE, SD; details in CTA-861-H 5.1) influences which
quantization range the sink expects.

This means that we have to expect that sometimes we have to send
limited and sometimes full range content. The big question however
that is not answered in the docs: who is responsible for making sure
the data is in the correct range? Is it the kernel or user space?

If it's the kernel: does user space supply full range or limited range
content? Each of those has a disadvantage. If we send full range
content and the driver scales it down to limited range, we can't use
the out-of-range bits to transfer information. If we send limited
range content and the driver scales it up we lose information.

Either way, this must be documented. My suggestion is to say that the
kernel always expects full range data as input and is responsible for
scaling it to limited range data if the sink expects limited range
data.

Another problem is that some displays do not behave correctly. It must
be possible to override the kernel when the user detects such a
situation. This override then controls if the driver converts the full
range data coming from the client or not (Default, Force Limited,
Force Full). It does not try to control what range the sink expects.
Let's call this the Quantization Range Override property which should
be implemented by all drivers.

All drivers should make sure their behavior is correct:

* check that drivers choose the correct default quantization range for
the selected mode
* whenever explicit control is available, use it and set the
quantization range to full
* make sure that the hardware converts from full range to limited
range whenever the sink expects limited range
* implement the Quantization Range Override property

I'm volunteering for the documentation, UAPI and maybe even the drm
core parts if there is willingness to tackle the issue.

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.

Re: The state of Quantization Range handling

[Dave Stevenson]

Hi Sebastian

Thanks for starting the conversation - it's stalled a number of times
previously.

On Mon, 14 Nov 2022 at 23:12, Sebastian Wick <sebastian.wick@redhat.com> wrote:
>
> There are still regular bug reports about monitors (sinks) and sources
> disagreeing about the quantization range of the pixel data. In
> particular sources sending full range data when the sink expects
> limited range. From a user space perspective, this is all hidden in
> the kernel. We send full range data to the kernel and then hope it
> does the right thing but as the bug reports show: some combinations of
> displays and drivers result in problems.

I'll agree that we as Raspberry Pi also get a number of bug reports
where sinks don't always look at the infoframes and misinterpret the
data.

> In general the whole handling of the quantization range on linux is
> not defined or documented at all. User space sends full range data
> because that's what seems to work most of the time but technically
> this is all undefined and user space can not fix those issues. Some
> compositors have resorted to giving users the option to choose the
> quantization range but this really should only be necessary for
> straight up broken hardware.

Wowsers! Making userspace worry about limited range data would be a
very weird decision in my view, so compositors should always deal in
full range data.

How would composition of multiple DRM planes work if some are limited
range and some are full but you want limited range output? Your
hardware needs to have CSC matrices to convert full range down to
limited range, and know that you want to use them to effectively
compose to limited range.
In fact you can't currently tell DRM that an RGB plane is limited
range - the values in enum drm_color_range are
DRM_COLOR_YCBCR_LIMITED_RANGE and DRM_COLOR_YCBCR_FULL_RANGE [1].

> Quantization Range can be explicitly controlled by AVI InfoFrame or
> HDMI General Control Packets. This is the ideal case and when the
> source uses them there is not a lot that can go wrong. Not all
> displays support those explicit controls in which case the chosen
> video format (IT, CE, SD; details in CTA-861-H 5.1) influences which
> quantization range the sink expects.
>
> This means that we have to expect that sometimes we have to send
> limited and sometimes full range content. The big question however
> that is not answered in the docs: who is responsible for making sure
> the data is in the correct range? Is it the kernel or user space?
>
> If it's the kernel: does user space supply full range or limited range
> content? Each of those has a disadvantage. If we send full range
> content and the driver scales it down to limited range, we can't use
> the out-of-range bits to transfer information. If we send limited
> range content and the driver scales it up we lose information.

How often have you encountered the out-of-range bits being used?
Personally I've never come across it. Is it really that common?
If trying to pass non-video data from the client then you need to pray
there is no scaling or filtering during composition as it could
legitimately be corrupted.

> Either way, this must be documented. My suggestion is to say that the
> kernel always expects full range data as input and is responsible for
> scaling it to limited range data if the sink expects limited range
> data.

AIUI That is the current situation. It certainly fits the way that all
our hardware works.

> Another problem is that some displays do not behave correctly. It must
> be possible to override the kernel when the user detects such a
> situation. This override then controls if the driver converts the full
> range data coming from the client or not (Default, Force Limited,
> Force Full). It does not try to control what range the sink expects.

Sorry, I'm not clear from the description. Is this a plane, crtc, or
connector property?

"Data coming from the client" would imply a plane property only -
effectively extending enum drm_color_range for RGB formats.

If it is a connector property then what do you mean by not controlling
the range? It doesn't change the AVI Infoframe or GCP and leaves the
sink thinking it is the default? If so, doesn't that mean this control
can now make a compliant sink incorrectly render the data? Assuming
the driver is using drm_hdmi_avi_infoframe_quant_range [2], then the
sink is likely to be told explicitly that it is one value which is
then actually wrong.


Or is this a flag to tell the crtc to compose all planes to a limited
range output, thereby updating all the CSC matrices used for RGB and
YCbCr planes? There's still no guarantee that the composition won't
clip the video to the specified output range thereby losing the out of
range values you carefully crafted.

> Let's call this the Quantization Range Override property which should
> be implemented by all drivers.
>
> All drivers should make sure their behavior is correct:
>
> * check that drivers choose the correct default quantization range for
> the selected mode
> * whenever explicit control is available, use it and set the
> quantization range to full
> * make sure that the hardware converts from full range to limited
> range whenever the sink expects limited range
> * implement the Quantization Range Override property
>
> I'm volunteering for the documentation, UAPI and maybe even the drm
> core parts if there is willingness to tackle the issue.
>
> 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.

As above, how real is that use case?

> Selecting Default never makes sense: relying on
> the default quantization range is risky because sinks often get it
> wrong

Sinks *sometimes* get it wrong. I'd suggest >99.99% of devices follow
the spec and get it right, and it's only the odd-balls that you need
an override for.

> and as we established there is no reason to select limited range
> if not necessary.

Not necessary based on what criteria?
eg The display's EDID CTA-861 extension block has said that it
supports VIC 16 for 1080p60. Looking at CTA-861-F (the version I had
to hand) section 5.1 therefore says that it should be encoded using
Limited Range as it is a CE video format. The first paragraph does
state:
"When present, encoding parameters specified in the AVI Infoframe, or
other interface-specific controls, shall take precedence over any
default parameter defined in this sub-section".
However then section 6.4 (page 58) when describing Q0 and Q1 states:
"A source shall not send a non-zero Q value that does not correspond
to the default RGB Quantization Range for the transmitted Picture
unless the Sink indicates support for the Q bit in a Video
Capabilities Data Block (see 7.5.6)"
So if this is being passed back to userspace to choose, it now needs
to be parsing the EDID to find the VCD block to work out which range
is permitted.
At least if this is done within the kernel it is done once (see
drm_default_rgb_quant_range() [3]) and that implementation should be
correct.

> 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.

The property being available or not would be an implementation
question. I see no conditionals in the i915 HDMI implementation on
whether "Broadcast RGB" is available or actioned based on the EDID.

Are you looking at this as a programmatically decided value, or as an
override for dealing with misbehaving sinks?
My view is that a fully auto mode deals with all devices that follow
the specs. These controls should only be needed for misbehaving sinks
or other very specific use cases where the user accepts they can ask
for something which the sink doesn't support (often deliberately).
There's no requirement to try and programmatically set them from
within a compositor or other system app.

This does then hit the issue of DRM requiring an open source project
implementing any new property. How do you do that when the control is
really an override for dodgy hardware rather than something that is
expected to be used programmatically? Time to drop back to a module
parameter then....

In the Raspberry Pi vendor kernel we have implemented "Broadcast RGB"
following the i915 pattern (and always effective), and I've yet to
have anyone report that it doesn't solve the problem with their sink.
It can make an HDMI analyser complain, but that's due to Q0 & Q1 being
set to a non-zero and non-default value when the EDID VCD doesn't
allow it, so not a big deal.


If you're starting a discussion on quantization, then there is also
the subject of switching between RGB and YCbCr 4:4:4 (or 4:2:2). I'll
agree it's less common to get a sink only accepting YCbCr, but I
actually had a support query over just that recently. Some software
using a Blackmagic Decklink Studio 4K capture card (our HDMI sink)
could only support YCbCr444 capture, and the software wasn't
configuring the hardware CSC of the card when fed RGB. It's largely
the same discussion: is it purely up to the kernel to choose, or does
userspace get to influence it?
So far all the discussions seem to have decided that the kernel should
just make the choice. However there is no system reason for choosing
YCbCr444 over RGB, and that leaves these stranger use cases out in the
cold and just not supportable under Linux. Let's go and recommend
Windows instead as generally this option will be under the advanced
options of the graphics driver :-(

Cheers.
  Dave

[1] https://elixir.bootlin.com/linux/latest/source/include/drm/drm_color_mgmt.h#L84
[2] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_edid.c#L6756
[3] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_edid.c#L5642

Re: The state of Quantization Range handling

[Yussuf Khalil]

Hello Sebastian,

I've previously done some work on this topic [1]. My efforts were mostly about 
fixing the situation regarding overrides and providing proper means for 
userspace. I am affected by the issue myself as I own several DELL U2414H 
screens that declare a CE mode as their preferred one, but should receive full 
range data nonetheless. They do not have the respective bit set in their EDID 
to indicate full range support either.

My implementation primarily moved the "Broadcast RGB" to DRM core and re-wired 
it in i915 and gma500. I further added a flag to indicate CE modes to userspace 
so that apps such as gnome-control-center can clearly communicate whether full 
or limited range would be used by default. A v2 branch that I never submitted 
is available at [2]. I also have some code lying around locally that adds the 
required functionality to mutter and gnome-control-center.

I had to pause work on the issue back then and never really came around to 
picking it up again, however, I would be interested in working on it again if 
there is consensus on the direction that my patches laid out. I did not 
consider use cases for the out-of-range bits though.

Regards
Yussuf

[1] https://patchwork.kernel.org/project/dri-devel/cover/20200413214024.46500-1-dev@pp3345.net/
[2] https://github.com/pp3345/linux/commits/rgb-quant-range-v2

On 15.11.22 00:11, Sebastian Wick wrote:
> There are still regular bug reports about monitors (sinks) and sources
> disagreeing about the quantization range of the pixel data. In
> particular sources sending full range data when the sink expects
> limited range. From a user space perspective, this is all hidden in
> the kernel. We send full range data to the kernel and then hope it
> does the right thing but as the bug reports show: some combinations of
> displays and drivers result in problems.
> 
> In general the whole handling of the quantization range on linux is
> not defined or documented at all. User space sends full range data
> because that's what seems to work most of the time but technically
> this is all undefined and user space can not fix those issues. Some
> compositors have resorted to giving users the option to choose the
> quantization range but this really should only be necessary for
> straight up broken hardware.
> 
> Quantization Range can be explicitly controlled by AVI InfoFrame or
> HDMI General Control Packets. This is the ideal case and when the
> source uses them there is not a lot that can go wrong. Not all
> displays support those explicit controls in which case the chosen
> video format (IT, CE, SD; details in CTA-861-H 5.1) influences which
> quantization range the sink expects.
> 
> This means that we have to expect that sometimes we have to send
> limited and sometimes full range content. The big question however
> that is not answered in the docs: who is responsible for making sure
> the data is in the correct range? Is it the kernel or user space?
> 
> If it's the kernel: does user space supply full range or limited range
> content? Each of those has a disadvantage. If we send full range
> content and the driver scales it down to limited range, we can't use
> the out-of-range bits to transfer information. If we send limited
> range content and the driver scales it up we lose information.
> 
> Either way, this must be documented. My suggestion is to say that the
> kernel always expects full range data as input and is responsible for
> scaling it to limited range data if the sink expects limited range
> data.
> 
> Another problem is that some displays do not behave correctly. It must
> be possible to override the kernel when the user detects such a
> situation. This override then controls if the driver converts the full
> range data coming from the client or not (Default, Force Limited,
> Force Full). It does not try to control what range the sink expects.
> Let's call this the Quantization Range Override property which should
> be implemented by all drivers.
> 
> All drivers should make sure their behavior is correct:
> 
> * check that drivers choose the correct default quantization range for
> the selected mode
> * whenever explicit control is available, use it and set the
> quantization range to full
> * make sure that the hardware converts from full range to limited
> range whenever the sink expects limited range
> * implement the Quantization Range Override property
> 
> I'm volunteering for the documentation, UAPI and maybe even the drm
> core parts if there is willingness to tackle the issue.
> 
> 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.
> 

Re: The state of Quantization Range handling

[Pekka Paalanen]

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

On Tue, 15 Nov 2022 00:11:56 +0100
Sebastian Wick <sebastian.wick@redhat.com> wrote:

> There are still regular bug reports about monitors (sinks) and sources
> disagreeing about the quantization range of the pixel data. In
> particular sources sending full range data when the sink expects
> limited range. From a user space perspective, this is all hidden in
> the kernel. We send full range data to the kernel and then hope it
> does the right thing but as the bug reports show: some combinations of
> displays and drivers result in problems.
> 
> In general the whole handling of the quantization range on linux is
> not defined or documented at all. User space sends full range data
> because that's what seems to work most of the time but technically
> this is all undefined and user space can not fix those issues. Some
> compositors have resorted to giving users the option to choose the
> quantization range but this really should only be necessary for
> straight up broken hardware.
> 
> Quantization Range can be explicitly controlled by AVI InfoFrame or
> HDMI General Control Packets. This is the ideal case and when the
> source uses them there is not a lot that can go wrong. Not all
> displays support those explicit controls in which case the chosen
> video format (IT, CE, SD; details in CTA-861-H 5.1) influences which
> quantization range the sink expects.
> 
> This means that we have to expect that sometimes we have to send
> limited and sometimes full range content. The big question however
> that is not answered in the docs: who is responsible for making sure
> the data is in the correct range? Is it the kernel or user space?
> 
> If it's the kernel: does user space supply full range or limited range
> content? Each of those has a disadvantage. If we send full range
> content and the driver scales it down to limited range, we can't use
> the out-of-range bits to transfer information. If we send limited
> range content and the driver scales it up we lose information.
> 
> Either way, this must be documented. My suggestion is to say that the
> kernel always expects full range data as input and is responsible for
> scaling it to limited range data if the sink expects limited range
> data.

Hi Sebastian,

you are proposing the that driver/hardware will do either no range
conversion, or full-to-limited range conversion. Limited-to-full range
conversion would never be supported.

I still wonder if limited-to-full range conversion could be useful with
video content.

> Another problem is that some displays do not behave correctly. It must
> be possible to override the kernel when the user detects such a
> situation. This override then controls if the driver converts the full
> range data coming from the client or not (Default, Force Limited,
> Force Full). It does not try to control what range the sink expects.
> Let's call this the Quantization Range Override property which should
> be implemented by all drivers.

In other words, a CRTC "quantization range conversion" property with
values:
- auto, with the assumption that color pipeline always produces full-range
- identity
- full-to-limited
(- limited-to-full)

If this property was truly independent of the metadata being sent to
the sink, and of the framebuffer format, it would allow us to do four
ways: both full/limited framebuffer on both full/limited sink. It would
allow us to send sub-blacks and super-whites as well.

More precisely, framebuffers would always have *undefined* quantization
range. The configuration of the color pipeline then determines how that
data is manipulated into a video signal.

So I am advocating the same design as with color spaces: do not tell
KMS what your colorspaces are. Instead tell KMS what operations it
needs to do with the pixel data, and what metadata to send to the sink.

> All drivers should make sure their behavior is correct:
> 
> * check that drivers choose the correct default quantization range for
> the selected mode

Mode implying a quantization range is awkward, but maybe the kernel
established modes should just have a flag for it. Then userspace would
know. Unless the video mode system is extended to communicate
IT/CE/SD/VIC and whatnot to userspace, making the modes better defined.
Then userspace would know too.

> * whenever explicit control is available, use it and set the
> quantization range to full
> * make sure that the hardware converts from full range to limited
> range whenever the sink expects limited range
> * implement the Quantization Range Override property
> 
> I'm volunteering for the documentation, UAPI and maybe even the drm
> core parts if there is willingness to tackle the issue.

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.


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.
> 


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

Re: The state of Quantization Range handling

[Sebastian Wick]

Hi Dave,

I noticed that I didn't get the Broadcast RGB property thanks to you
(more below)

On Tue, Nov 15, 2022 at 2:16 PM Dave Stevenson
<dave.stevenson@raspberrypi.com> wrote:
>
> Hi Sebastian
>
> Thanks for starting the conversation - it's stalled a number of times
> previously.
>
> On Mon, 14 Nov 2022 at 23:12, Sebastian Wick <sebastian.wick@redhat.com> wrote:
> >
> > There are still regular bug reports about monitors (sinks) and sources
> > disagreeing about the quantization range of the pixel data. In
> > particular sources sending full range data when the sink expects
> > limited range. From a user space perspective, this is all hidden in
> > the kernel. We send full range data to the kernel and then hope it
> > does the right thing but as the bug reports show: some combinations of
> > displays and drivers result in problems.
>
> I'll agree that we as Raspberry Pi also get a number of bug reports
> where sinks don't always look at the infoframes and misinterpret the
> data.
>
> > In general the whole handling of the quantization range on linux is
> > not defined or documented at all. User space sends full range data
> > because that's what seems to work most of the time but technically
> > this is all undefined and user space can not fix those issues. Some
> > compositors have resorted to giving users the option to choose the
> > quantization range but this really should only be necessary for
> > straight up broken hardware.
>
> Wowsers! Making userspace worry about limited range data would be a
> very weird decision in my view, so compositors should always deal in
> full range data.

Making this a user space problem is IMO the ideal way to deal with it
but that's a bit harder to do (I'll answer that in the reply to
Pekka). So let's just assume we all agree that user space only deals
with full range data.

> How would composition of multiple DRM planes work if some are limited
> range and some are full but you want limited range output? Your
> hardware needs to have CSC matrices to convert full range down to
> limited range, and know that you want to use them to effectively
> compose to limited range.
> In fact you can't currently tell DRM that an RGB plane is limited
> range - the values in enum drm_color_range are
> DRM_COLOR_YCBCR_LIMITED_RANGE and DRM_COLOR_YCBCR_FULL_RANGE [1].
>
> > Quantization Range can be explicitly controlled by AVI InfoFrame or
> > HDMI General Control Packets. This is the ideal case and when the
> > source uses them there is not a lot that can go wrong. Not all
> > displays support those explicit controls in which case the chosen
> > video format (IT, CE, SD; details in CTA-861-H 5.1) influences which
> > quantization range the sink expects.
> >
> > This means that we have to expect that sometimes we have to send
> > limited and sometimes full range content. The big question however
> > that is not answered in the docs: who is responsible for making sure
> > the data is in the correct range? Is it the kernel or user space?
> >
> > If it's the kernel: does user space supply full range or limited range
> > content? Each of those has a disadvantage. If we send full range
> > content and the driver scales it down to limited range, we can't use
> > the out-of-range bits to transfer information. If we send limited
> > range content and the driver scales it up we lose information.
>
> How often have you encountered the out-of-range bits being used?
> Personally I've never come across it. Is it really that common?
> If trying to pass non-video data from the client then you need to pray
> there is no scaling or filtering during composition as it could
> legitimately be corrupted.

All true, and personally I've also never encountered this which is why
I'd like to ignore all of that for now.

>
> > Either way, this must be documented. My suggestion is to say that the
> > kernel always expects full range data as input and is responsible for
> > scaling it to limited range data if the sink expects limited range
> > data.
>
> AIUI That is the current situation. It certainly fits the way that all
> our hardware works.
>
> > Another problem is that some displays do not behave correctly. It must
> > be possible to override the kernel when the user detects such a
> > situation. This override then controls if the driver converts the full
> > range data coming from the client or not (Default, Force Limited,
> > Force Full). It does not try to control what range the sink expects.
>
> Sorry, I'm not clear from the description. Is this a plane, crtc, or
> connector property?
>
> "Data coming from the client" would imply a plane property only -
> effectively extending enum drm_color_range for RGB formats.
>
> If it is a connector property then what do you mean by not controlling
> the range? It doesn't change the AVI Infoframe or GCP and leaves the
> sink thinking it is the default? If so, doesn't that mean this control
> can now make a compliant sink incorrectly render the data? Assuming
> the driver is using drm_hdmi_avi_infoframe_quant_range [2], then the
> sink is likely to be told explicitly that it is one value which is
> then actually wrong.
>
>
> Or is this a flag to tell the crtc to compose all planes to a limited
> range output, thereby updating all the CSC matrices used for RGB and
> YCbCr planes? There's still no guarantee that the composition won't
> clip the video to the specified output range thereby losing the out of
> range values you carefully crafted.
>
> > Let's call this the Quantization Range Override property which should
> > be implemented by all drivers.
> >
> > All drivers should make sure their behavior is correct:
> >
> > * check that drivers choose the correct default quantization range for
> > the selected mode
> > * whenever explicit control is available, use it and set the
> > quantization range to full
> > * make sure that the hardware converts from full range to limited
> > range whenever the sink expects limited range
> > * implement the Quantization Range Override property
> >
> > I'm volunteering for the documentation, UAPI and maybe even the drm
> > core parts if there is willingness to tackle the issue.
> >
> > 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.
>
> As above, how real is that use case?

I don't know. Nobody was able to use those bits before so it's hard to
tell but like I said before, I think this can be ignored for now.

>
> > Selecting Default never makes sense: relying on
> > the default quantization range is risky because sinks often get it
> > wrong
>
> Sinks *sometimes* get it wrong. I'd suggest >99.99% of devices follow
> the spec and get it right, and it's only the odd-balls that you need
> an override for.
>
> > and as we established there is no reason to select limited range
> > if not necessary.
>
> Not necessary based on what criteria?
> eg The display's EDID CTA-861 extension block has said that it
> supports VIC 16 for 1080p60. Looking at CTA-861-F (the version I had
> to hand) section 5.1 therefore says that it should be encoded using
> Limited Range as it is a CE video format. The first paragraph does
> state:
> "When present, encoding parameters specified in the AVI Infoframe, or
> other interface-specific controls, shall take precedence over any
> default parameter defined in this sub-section".
> However then section 6.4 (page 58) when describing Q0 and Q1 states:
> "A source shall not send a non-zero Q value that does not correspond
> to the default RGB Quantization Range for the transmitted Picture
> unless the Sink indicates support for the Q bit in a Video
> Capabilities Data Block (see 7.5.6)"
> So if this is being passed back to userspace to choose, it now needs
> to be parsing the EDID to find the VCD block to work out which range
> is permitted.
> At least if this is done within the kernel it is done once (see
> drm_default_rgb_quant_range() [3]) and that implementation should be
> correct.
>
> > 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.
>
> The property being available or not would be an implementation
> question. I see no conditionals in the i915 HDMI implementation on
> whether "Broadcast RGB" is available or actioned based on the EDID.
>
> Are you looking at this as a programmatically decided value, or as an
> override for dealing with misbehaving sinks?
> My view is that a fully auto mode deals with all devices that follow
> the specs. These controls should only be needed for misbehaving sinks
> or other very specific use cases where the user accepts they can ask
> for something which the sink doesn't support (often deliberately).
> There's no requirement to try and programmatically set them from
> within a compositor or other system app.
>
> This does then hit the issue of DRM requiring an open source project
> implementing any new property. How do you do that when the control is
> really an override for dodgy hardware rather than something that is
> expected to be used programmatically? Time to drop back to a module
> parameter then....
>
> In the Raspberry Pi vendor kernel we have implemented "Broadcast RGB"
> following the i915 pattern (and always effective), and I've yet to
> have anyone report that it doesn't solve the problem with their sink.
> It can make an HDMI analyser complain, but that's due to Q0 & Q1 being
> set to a non-zero and non-default value when the EDID VCD doesn't
> allow it, so not a big deal.

You know what, this confused me because it's not how I thought the
"Broadcast RGB" behaves so I checked the code and it does indeed what
you say. I probably should have done that before.

The only complaint I have is that when the property is set to "Auto"
and the sink can accept full range data, it still might choose limited
range because it follows the default quantization range behavior. The
other two options indeed force the driver to output either limited or
full range content, even if that's not what the sink expects. It's not
good that as a user space developer I have to literally read the code
of a specific kernel driver to understand what a KMS property does.

So I guess what I'm advocating for is to move the Broadcast RGB
property to core DRM, document everything correctly, prefer full range
with "Auto" selected, and implement it for all the drivers.

>
>
> If you're starting a discussion on quantization, then there is also
> the subject of switching between RGB and YCbCr 4:4:4 (or 4:2:2). I'll
> agree it's less common to get a sink only accepting YCbCr, but I
> actually had a support query over just that recently. Some software
> using a Blackmagic Decklink Studio 4K capture card (our HDMI sink)
> could only support YCbCr444 capture, and the software wasn't
> configuring the hardware CSC of the card when fed RGB. It's largely
> the same discussion: is it purely up to the kernel to choose, or does
> userspace get to influence it?
> So far all the discussions seem to have decided that the kernel should
> just make the choice. However there is no system reason for choosing
> YCbCr444 over RGB, and that leaves these stranger use cases out in the
> cold and just not supportable under Linux. Let's go and recommend
> Windows instead as generally this option will be under the advanced
> options of the graphics driver :-(

Yes, that's also on my list of horribly broken things that need fixing.

The other extreme is AMD basically always choosing YCC over RGB to
reduce the bandwidth resulting in bad text rendition.

Then there is the Colorspace infoframe which requires choosing YCC and
RGB color space variants which is literally impossible to do correctly
because user space simply does not know.

>
> Cheers.
>   Dave
>
> [1] https://elixir.bootlin.com/linux/latest/source/include/drm/drm_color_mgmt.h#L84
> [2] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_edid.c#L6756
> [3] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_edid.c#L5642
>

Re: The state of Quantization Range handling

[Sebastian Wick]

Hi Yussuf,

On Tue, Nov 15, 2022 at 5:26 PM Yussuf Khalil <dev@pp3345.net> wrote:
>
> Hello Sebastian,
>
> I've previously done some work on this topic [1]. My efforts were mostly about
> fixing the situation regarding overrides and providing proper means for
> userspace. I am affected by the issue myself as I own several DELL U2414H
> screens that declare a CE mode as their preferred one, but should receive full
> range data nonetheless. They do not have the respective bit set in their EDID
> to indicate full range support either.
>
> My implementation primarily moved the "Broadcast RGB" to DRM core and re-wired
> it in i915 and gma500. I further added a flag to indicate CE modes to userspace
> so that apps such as gnome-control-center can clearly communicate whether full
> or limited range would be used by default. A v2 branch that I never submitted
> is available at [2]. I also have some code lying around locally that adds the
> required functionality to mutter and gnome-control-center.

Yeah, I now agree that moving the "Broadcast RGB" to DRM core would be
a good decision. The slight behavior change I want to see can be done
afterwards as well. Not so sure about indicating CE modes because
there are other factors (YCC vs RGB, the connector type and version)
which influence the default quantization range.

>
> I had to pause work on the issue back then and never really came around to
> picking it up again, however, I would be interested in working on it again if
> there is consensus on the direction that my patches laid out. I did not
> consider use cases for the out-of-range bits though.

I think we can safely ignore out-of-range bits for now and good to
know you're on board.

>
> Regards
> Yussuf
>
> [1] https://patchwork.kernel.org/project/dri-devel/cover/20200413214024.46500-1-dev@pp3345.net/
> [2] https://github.com/pp3345/linux/commits/rgb-quant-range-v2
>
> On 15.11.22 00:11, Sebastian Wick wrote:
> > There are still regular bug reports about monitors (sinks) and sources
> > disagreeing about the quantization range of the pixel data. In
> > particular sources sending full range data when the sink expects
> > limited range. From a user space perspective, this is all hidden in
> > the kernel. We send full range data to the kernel and then hope it
> > does the right thing but as the bug reports show: some combinations of
> > displays and drivers result in problems.
> >
> > In general the whole handling of the quantization range on linux is
> > not defined or documented at all. User space sends full range data
> > because that's what seems to work most of the time but technically
> > this is all undefined and user space can not fix those issues. Some
> > compositors have resorted to giving users the option to choose the
> > quantization range but this really should only be necessary for
> > straight up broken hardware.
> >
> > Quantization Range can be explicitly controlled by AVI InfoFrame or
> > HDMI General Control Packets. This is the ideal case and when the
> > source uses them there is not a lot that can go wrong. Not all
> > displays support those explicit controls in which case the chosen
> > video format (IT, CE, SD; details in CTA-861-H 5.1) influences which
> > quantization range the sink expects.
> >
> > This means that we have to expect that sometimes we have to send
> > limited and sometimes full range content. The big question however
> > that is not answered in the docs: who is responsible for making sure
> > the data is in the correct range? Is it the kernel or user space?
> >
> > If it's the kernel: does user space supply full range or limited range
> > content? Each of those has a disadvantage. If we send full range
> > content and the driver scales it down to limited range, we can't use
> > the out-of-range bits to transfer information. If we send limited
> > range content and the driver scales it up we lose information.
> >
> > Either way, this must be documented. My suggestion is to say that the
> > kernel always expects full range data as input and is responsible for
> > scaling it to limited range data if the sink expects limited range
> > data.
> >
> > Another problem is that some displays do not behave correctly. It must
> > be possible to override the kernel when the user detects such a
> > situation. This override then controls if the driver converts the full
> > range data coming from the client or not (Default, Force Limited,
> > Force Full). It does not try to control what range the sink expects.
> > Let's call this the Quantization Range Override property which should
> > be implemented by all drivers.
> >
> > All drivers should make sure their behavior is correct:
> >
> > * check that drivers choose the correct default quantization range for
> > the selected mode
> > * whenever explicit control is available, use it and set the
> > quantization range to full
> > * make sure that the hardware converts from full range to limited
> > range whenever the sink expects limited range
> > * implement the Quantization Range Override property
> >
> > I'm volunteering for the documentation, UAPI and maybe even the drm
> > core parts if there is willingness to tackle the issue.
> >
> > 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.
> >
>

Re: The state of Quantization Range handling

[Sebastian Wick]

On Wed, Nov 16, 2022 at 1:34 PM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Tue, 15 Nov 2022 00:11:56 +0100
> Sebastian Wick <sebastian.wick@redhat.com> wrote:
>
> > There are still regular bug reports about monitors (sinks) and sources
> > disagreeing about the quantization range of the pixel data. In
> > particular sources sending full range data when the sink expects
> > limited range. From a user space perspective, this is all hidden in
> > the kernel. We send full range data to the kernel and then hope it
> > does the right thing but as the bug reports show: some combinations of
> > displays and drivers result in problems.
> >
> > In general the whole handling of the quantization range on linux is
> > not defined or documented at all. User space sends full range data
> > because that's what seems to work most of the time but technically
> > this is all undefined and user space can not fix those issues. Some
> > compositors have resorted to giving users the option to choose the
> > quantization range but this really should only be necessary for
> > straight up broken hardware.
> >
> > Quantization Range can be explicitly controlled by AVI InfoFrame or
> > HDMI General Control Packets. This is the ideal case and when the
> > source uses them there is not a lot that can go wrong. Not all
> > displays support those explicit controls in which case the chosen
> > video format (IT, CE, SD; details in CTA-861-H 5.1) influences which
> > quantization range the sink expects.
> >
> > This means that we have to expect that sometimes we have to send
> > limited and sometimes full range content. The big question however
> > that is not answered in the docs: who is responsible for making sure
> > the data is in the correct range? Is it the kernel or user space?
> >
> > If it's the kernel: does user space supply full range or limited range
> > content? Each of those has a disadvantage. If we send full range
> > content and the driver scales it down to limited range, we can't use
> > the out-of-range bits to transfer information. If we send limited
> > range content and the driver scales it up we lose information.
> >
> > Either way, this must be documented. My suggestion is to say that the
> > kernel always expects full range data as input and is responsible for
> > scaling it to limited range data if the sink expects limited range
> > data.
>
> Hi Sebastian,
>
> you are proposing the that driver/hardware will do either no range
> conversion, or full-to-limited range conversion. Limited-to-full range
> conversion would never be supported.
>
> I still wonder if limited-to-full range conversion could be useful with
> video content.
>
> > Another problem is that some displays do not behave correctly. It must
> > be possible to override the kernel when the user detects such a
> > situation. This override then controls if the driver converts the full
> > range data coming from the client or not (Default, Force Limited,
> > Force Full). It does not try to control what range the sink expects.
> > Let's call this the Quantization Range Override property which should
> > be implemented by all drivers.
>
> In other words, a CRTC "quantization range conversion" property with
> values:
> - auto, with the assumption that color pipeline always produces full-range
> - identity
> - full-to-limited
> (- limited-to-full)
>
> If this property was truly independent of the metadata being sent to
> the sink, and of the framebuffer format, it would allow us to do four
> ways: both full/limited framebuffer on both full/limited sink. It would
> allow us to send sub-blacks and super-whites as well.
>
> More precisely, framebuffers would always have *undefined* quantization
> range. The configuration of the color pipeline then determines how that
> data is manipulated into a video signal.
>
> So I am advocating the same design as with color spaces: do not tell
> KMS what your colorspaces are. Instead tell KMS what operations it
> needs to do with the pixel data, and what metadata to send to the sink.
>
> > All drivers should make sure their behavior is correct:
> >
> > * check that drivers choose the correct default quantization range for
> > the selected mode
>
> Mode implying a quantization range is awkward, but maybe the kernel
> established modes should just have a flag for it. Then userspace would
> know. Unless the video mode system is extended to communicate
> IT/CE/SD/VIC and whatnot to userspace, making the modes better defined.
> Then userspace would know too.
>
> > * whenever explicit control is available, use it and set the
> > quantization range to full
> > * make sure that the hardware converts from full range to limited
> > range whenever the sink expects limited range
> > * implement the Quantization Range Override property
> >
> > I'm volunteering for the documentation, UAPI and maybe even the drm
> > core parts if there is willingness to tackle the issue.
>
> 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?

>
>
> 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

Re: The state of Quantization Range handling

[Pekka Paalanen]

[-- 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 --]

Re: The state of Quantization Range handling

[Pekka Paalanen]

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

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

> Hi Dave,
> 
> I noticed that I didn't get the Broadcast RGB property thanks to you
> (more below)
> 
> On Tue, Nov 15, 2022 at 2:16 PM Dave Stevenson
> <dave.stevenson@raspberrypi.com> wrote:
> >
> > Hi Sebastian
> >
> > Thanks for starting the conversation - it's stalled a number of times
> > previously.
> >
> > On Mon, 14 Nov 2022 at 23:12, Sebastian Wick <sebastian.wick@redhat.com> wrote:  
> > >
> > > There are still regular bug reports about monitors (sinks) and sources
> > > disagreeing about the quantization range of the pixel data. In
> > > particular sources sending full range data when the sink expects
> > > limited range. From a user space perspective, this is all hidden in
> > > the kernel. We send full range data to the kernel and then hope it
> > > does the right thing but as the bug reports show: some combinations of
> > > displays and drivers result in problems.  
> >
> > I'll agree that we as Raspberry Pi also get a number of bug reports
> > where sinks don't always look at the infoframes and misinterpret the
> > data.
> >  
> > > In general the whole handling of the quantization range on linux is
> > > not defined or documented at all. User space sends full range data
> > > because that's what seems to work most of the time but technically
> > > this is all undefined and user space can not fix those issues. Some
> > > compositors have resorted to giving users the option to choose the
> > > quantization range but this really should only be necessary for
> > > straight up broken hardware.  
> >
> > Wowsers! Making userspace worry about limited range data would be a
> > very weird decision in my view, so compositors should always deal in
> > full range data.  
> 
> Making this a user space problem is IMO the ideal way to deal with it
> but that's a bit harder to do (I'll answer that in the reply to
> Pekka). So let's just assume we all agree that user space only deals
> with full range data.

Limited range was invented for some reason, so it must have some use
somewhere, at least in the past. Maybe it was needed to calibrate mixed
digital/analog video processing chains with test images that needed to
contain sub-blacks and super-whites, to make sure that sub-blacks come
out as the nominal black etc. Just because desktop computers do not
seem to have any need for limited range, I personally wouldn't be as
arrogant as to say it's never useful. Maybe there are professional
video/broadcasting needs that currently can only be realized with
proprietary OS/hardware, because Linux just can't do it today?

Why would TVs support limited range, if it was never useful? Why would
video sources produce limited range if it was always strictly inferior
to full range?

Even digital image processing algorithms might make use of
out-of-unit-range values, not just analog circuitry for overshoot.

But no, I can't give a real example, just speculation. Hence it's fine
by me to discard limited range processing for now. Still, what I
explain below would allow limited range processing without any extra
complexity by making the KMS color pipeline better defined and less
limiting for userspace.

> > How would composition of multiple DRM planes work if some are limited
> > range and some are full but you want limited range output? Your
> > hardware needs to have CSC matrices to convert full range down to
> > limited range, and know that you want to use them to effectively
> > compose to limited range.
> > In fact you can't currently tell DRM that an RGB plane is limited
> > range - the values in enum drm_color_range are
> > DRM_COLOR_YCBCR_LIMITED_RANGE and DRM_COLOR_YCBCR_FULL_RANGE [1].

Yeah, that's because range conversion has been conflated with
YUV-to-RGB conversion, and the result is always full-range RGB in
practise, AFAIU. There is no way to feed limited range color into the
further color pipeline in KMS, but that's actually a good thing.(*)

The following is my opinion of the future, as someone who has been
thinking about how to make HDR work on Wayland while allowing the
display quality and hardware optimizations that Wayland was designed
for:


Userspace should not tell KMS about a plane being limited range at all.
The reason is the same why userspace should not tell KMS about what
colorspace a plane is in.

Instead, userspace wants to program specific mathematical operations
into KMS hardware without any associated or implied semantics. It's
just math. The actual semantics have been worked out by userspace
before-hand. This allows to use the KMS hardware to its fullest effect,
even for things the hardware or KMS UAPI designers did not anticipate.

IMO, framebuffers and KMS planes should ultimately be in undefined
quantization range, undefined color space, and undefined dynamic range.
The correct processing of the pixel values is programmed by per-plane
KMS properties like CTM, LUT, and more specialized components like
quantization range converter or YUV-to-RGB converter (which is just
another CTM at a different point, really) where userspace explicitly
programs the *operation*, and not the input and output types hoping the
driver and hardware does something sensible.

In that design, there is no problem at all to blend multiple planes of
differing quantization ranges together. Userspace first chooses the
blending space, a radiometrically linear RGB limited range BT.709 space
for example, and then programs each plane to produce exactly that. Then
CRTC properties are programmed to produce the desired type of output
signal. Finally, connector properties are programmed to send the
appropriate metadata to the sink. Of course, userspace takes the sink
capabilities into account before deciding all this.

The thing KMS UAPI is missing are the per-plane properties.

(*) The reason it is a good thing that one cannot have limited range
framebuffers is that it would raise problems on how to handle pixel
values outside of the nominal range, that is, the sub-black and
super-white channel values. The immediate problem is that LUT stages
need normalized input and they cannot extrapolate. So if nominal
quantization range is normalized to 0.0-1.0 for LUT input, sub-black
would be negative values and super-white would be greater than 1.0
values, which a LUT cannot sensibly handle. That makes the whole
concept of limited range problematic in the color pipeline. But, if the
color pipeline elements like LUTs are defined *as if* the data was
always full range, it becomes well-defined and useful how the elements
work, and userspace can produce a proper programming that is guaranteed
to work.

By completely removing the concept of quantization range and its
"automatic" handling from the KMS color pipeline and adding processing
elements to do scaling+offset at suitable stages, we gain the ability
to accept, process, blend, and produce pixels in any quantization
range, color space or dynamic range at will.

Another thing such an approach solves is how to interpret
floating-point pixel data which can naturally represent
out-of-unit-range values.


Thanks,
pq

> > Cheers.
> >   Dave
> >
> > [1] https://elixir.bootlin.com/linux/latest/source/include/drm/drm_color_mgmt.h#L84
> > [2] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_edid.c#L6756
> > [3] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_edid.c#L5642
> >  
> 


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

Re: The state of Quantization Range handling

[Dave Stevenson]

Hi Pekka

On Fri, 18 Nov 2022 at 10:15, Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Thu, 17 Nov 2022 22:13:26 +0100
> Sebastian Wick <sebastian.wick@redhat.com> wrote:
>
> > Hi Dave,
> >
> > I noticed that I didn't get the Broadcast RGB property thanks to you
> > (more below)
> >
> > On Tue, Nov 15, 2022 at 2:16 PM Dave Stevenson
> > <dave.stevenson@raspberrypi.com> wrote:
> > >
> > > Hi Sebastian
> > >
> > > Thanks for starting the conversation - it's stalled a number of times
> > > previously.
> > >
> > > On Mon, 14 Nov 2022 at 23:12, Sebastian Wick <sebastian.wick@redhat.com> wrote:
> > > >
> > > > There are still regular bug reports about monitors (sinks) and sources
> > > > disagreeing about the quantization range of the pixel data. In
> > > > particular sources sending full range data when the sink expects
> > > > limited range. From a user space perspective, this is all hidden in
> > > > the kernel. We send full range data to the kernel and then hope it
> > > > does the right thing but as the bug reports show: some combinations of
> > > > displays and drivers result in problems.
> > >
> > > I'll agree that we as Raspberry Pi also get a number of bug reports
> > > where sinks don't always look at the infoframes and misinterpret the
> > > data.
> > >
> > > > In general the whole handling of the quantization range on linux is
> > > > not defined or documented at all. User space sends full range data
> > > > because that's what seems to work most of the time but technically
> > > > this is all undefined and user space can not fix those issues. Some
> > > > compositors have resorted to giving users the option to choose the
> > > > quantization range but this really should only be necessary for
> > > > straight up broken hardware.
> > >
> > > Wowsers! Making userspace worry about limited range data would be a
> > > very weird decision in my view, so compositors should always deal in
> > > full range data.
> >
> > Making this a user space problem is IMO the ideal way to deal with it
> > but that's a bit harder to do (I'll answer that in the reply to
> > Pekka). So let's just assume we all agree that user space only deals
> > with full range data.
>
> Limited range was invented for some reason, so it must have some use
> somewhere, at least in the past. Maybe it was needed to calibrate mixed
> digital/analog video processing chains with test images that needed to
> contain sub-blacks and super-whites, to make sure that sub-blacks come
> out as the nominal black etc. Just because desktop computers do not
> seem to have any need for limited range, I personally wouldn't be as
> arrogant as to say it's never useful. Maybe there are professional
> video/broadcasting needs that currently can only be realized with
> proprietary OS/hardware, because Linux just can't do it today?
>
> Why would TVs support limited range, if it was never useful? Why would
> video sources produce limited range if it was always strictly inferior
> to full range?
>
> Even digital image processing algorithms might make use of
> out-of-unit-range values, not just analog circuitry for overshoot.
>
> But no, I can't give a real example, just speculation. Hence it's fine
> by me to discard limited range processing for now. Still, what I
> explain below would allow limited range processing without any extra
> complexity by making the KMS color pipeline better defined and less
> limiting for userspace.

AIUI limited range comes from the analogue world, or possibly creative
(film/TV) world, hence being used on Consumer devices rather than IT
ones (CTA and CEA modes vs VESA and DMT modes).

YCbCr output from video codecs typically uses a range of 16-235,
therefore a media player wanting to pass the decoded video out to the
display exactly as-is needs to be able to signal that to the display
for it to be interpreted correctly.
HDMI extended DVI. I believe both YCbCr support and range control were
added to the HDMI spec at the same time, presumably to allow for this
use case. Limited range RGB seems to be a bit of a quirk though.

Just to be annoying, JPEG uses full range YCbCr.

> > > How would composition of multiple DRM planes work if some are limited
> > > range and some are full but you want limited range output? Your
> > > hardware needs to have CSC matrices to convert full range down to
> > > limited range, and know that you want to use them to effectively
> > > compose to limited range.
> > > In fact you can't currently tell DRM that an RGB plane is limited
> > > range - the values in enum drm_color_range are
> > > DRM_COLOR_YCBCR_LIMITED_RANGE and DRM_COLOR_YCBCR_FULL_RANGE [1].
>
> Yeah, that's because range conversion has been conflated with
> YUV-to-RGB conversion, and the result is always full-range RGB in
> practise, AFAIU. There is no way to feed limited range color into the
> further color pipeline in KMS, but that's actually a good thing.(*)
>
> The following is my opinion of the future, as someone who has been
> thinking about how to make HDR work on Wayland while allowing the
> display quality and hardware optimizations that Wayland was designed
> for:
>
>
> Userspace should not tell KMS about a plane being limited range at all.
> The reason is the same why userspace should not tell KMS about what
> colorspace a plane is in.
>
> Instead, userspace wants to program specific mathematical operations
> into KMS hardware without any associated or implied semantics. It's
> just math. The actual semantics have been worked out by userspace
> before-hand. This allows to use the KMS hardware to its fullest effect,
> even for things the hardware or KMS UAPI designers did not anticipate.
>
> IMO, framebuffers and KMS planes should ultimately be in undefined
> quantization range, undefined color space, and undefined dynamic range.
> The correct processing of the pixel values is programmed by per-plane
> KMS properties like CTM, LUT, and more specialized components like
> quantization range converter or YUV-to-RGB converter (which is just
> another CTM at a different point, really) where userspace explicitly
> programs the *operation*, and not the input and output types hoping the
> driver and hardware does something sensible.

How do you describe the functionality available on constrained
hardware that has fixed matrices for YUV to RGB conversions using the
normal BT601 and 709?
Or hardware that has no per plane matrix for RGB? (I believe vc4 fits
into this category).

I'd also propose that you need a load of helpers so that the "normal"
use cases of eg BT601 YCbCr to the default composition space is
handled for simply. Otherwise the enforced complexity to userspace has
just exploded.

Or seeing as properties like COLOR_ENCODING and COLOR_RANGE already
exist in the UAPI, add a "custom" mode to those that will enable all
your other magic properties.

> In that design, there is no problem at all to blend multiple planes of
> differing quantization ranges together. Userspace first chooses the
> blending space, a radiometrically linear RGB limited range BT.709 space
> for example, and then programs each plane to produce exactly that. Then
> CRTC properties are programmed to produce the desired type of output
> signal. Finally, connector properties are programmed to send the
> appropriate metadata to the sink. Of course, userspace takes the sink
> capabilities into account before deciding all this.
>
> The thing KMS UAPI is missing are the per-plane properties.

And hardware support on many platforms.
I've just checked, and vc4 always composes to RGB. Things like YCbCr
for HDMI are handled in the HDMI tx block. How do we tell userspace
that it has no choice over the blending space?

If you're trying to make things totally comprehensive, please don't
miss out chroma-siting as that is another property that is missing
from KMS for YCbCr planes.
MPEG-2, MPEG-4 and H264 differ from JPEG and MPEG-1 in default
chroma-siting, and HEVC differs again.

Conversion of HDR to/from SDR is going to be an interesting problem on
many platforms. I won't claim enough knowledge on the subject, but
obviously there needs to be a choice made over which mode composition
should happen in, and other planes will need to be converted. Is that
conversion going to be totally generic?


Lots of questions posed by this discussion, but I'm not sure that they
are specifically relevant to HDMI quantization ranges at this stage.
All RGB buffers should be full range, and full/limited range
conversion should be controlled via a similar mechanism to "Broadcast
RGB" but in the KMS core.

Checking drm_hdmi_avi_infoframe_quant_range(), it already does the
correct thing with regard to the EDID VCD block and signalling the
quantization range. The implementation of range choice on i915 (and
vendor vc4 tree) could be improved to also check
display_info->rgb_quant_range_selectable and choose FULL even for CEA
modes if the display allows it, but that may expose more compatibility
issues with monitors where the EDID is a little iffy.

Cheers
  Dave

> (*) The reason it is a good thing that one cannot have limited range
> framebuffers is that it would raise problems on how to handle pixel
> values outside of the nominal range, that is, the sub-black and
> super-white channel values. The immediate problem is that LUT stages
> need normalized input and they cannot extrapolate. So if nominal
> quantization range is normalized to 0.0-1.0 for LUT input, sub-black
> would be negative values and super-white would be greater than 1.0
> values, which a LUT cannot sensibly handle. That makes the whole
> concept of limited range problematic in the color pipeline. But, if the
> color pipeline elements like LUTs are defined *as if* the data was
> always full range, it becomes well-defined and useful how the elements
> work, and userspace can produce a proper programming that is guaranteed
> to work.
>
> By completely removing the concept of quantization range and its
> "automatic" handling from the KMS color pipeline and adding processing
> elements to do scaling+offset at suitable stages, we gain the ability
> to accept, process, blend, and produce pixels in any quantization
> range, color space or dynamic range at will.
>
> Another thing such an approach solves is how to interpret
> floating-point pixel data which can naturally represent
> out-of-unit-range values.
>
>
> Thanks,
> pq
>
> > > Cheers.
> > >   Dave
> > >
> > > [1] https://elixir.bootlin.com/linux/latest/source/include/drm/drm_color_mgmt.h#L84
> > > [2] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_edid.c#L6756
> > > [3] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_edid.c#L5642
> > >
> >
>

Re: The state of Quantization Range handling

[Harry Wentland]

On 11/18/22 10:53, Dave Stevenson wrote:
> Hi Pekka
> 
> On Fri, 18 Nov 2022 at 10:15, Pekka Paalanen <ppaalanen@gmail.com> wrote:
>>
>> On Thu, 17 Nov 2022 22:13:26 +0100
>> Sebastian Wick <sebastian.wick@redhat.com> wrote:
>>
>>> Hi Dave,
>>>
>>> I noticed that I didn't get the Broadcast RGB property thanks to you
>>> (more below)
>>>
>>> On Tue, Nov 15, 2022 at 2:16 PM Dave Stevenson
>>> <dave.stevenson@raspberrypi.com> wrote:
>>>>
>>>> Hi Sebastian
>>>>
>>>> Thanks for starting the conversation - it's stalled a number of times
>>>> previously.
>>>>
>>>> On Mon, 14 Nov 2022 at 23:12, Sebastian Wick <sebastian.wick@redhat.com> wrote:
>>>>>
>>>>> There are still regular bug reports about monitors (sinks) and sources
>>>>> disagreeing about the quantization range of the pixel data. In
>>>>> particular sources sending full range data when the sink expects
>>>>> limited range. From a user space perspective, this is all hidden in
>>>>> the kernel. We send full range data to the kernel and then hope it
>>>>> does the right thing but as the bug reports show: some combinations of
>>>>> displays and drivers result in problems.
>>>>
>>>> I'll agree that we as Raspberry Pi also get a number of bug reports
>>>> where sinks don't always look at the infoframes and misinterpret the
>>>> data.
>>>>
>>>>> In general the whole handling of the quantization range on linux is
>>>>> not defined or documented at all. User space sends full range data
>>>>> because that's what seems to work most of the time but technically
>>>>> this is all undefined and user space can not fix those issues. Some
>>>>> compositors have resorted to giving users the option to choose the
>>>>> quantization range but this really should only be necessary for
>>>>> straight up broken hardware.
>>>>
>>>> Wowsers! Making userspace worry about limited range data would be a
>>>> very weird decision in my view, so compositors should always deal in
>>>> full range data.
>>>
>>> Making this a user space problem is IMO the ideal way to deal with it
>>> but that's a bit harder to do (I'll answer that in the reply to
>>> Pekka). So let's just assume we all agree that user space only deals
>>> with full range data.
>>
>> Limited range was invented for some reason, so it must have some use
>> somewhere, at least in the past. Maybe it was needed to calibrate mixed
>> digital/analog video processing chains with test images that needed to
>> contain sub-blacks and super-whites, to make sure that sub-blacks come
>> out as the nominal black etc. Just because desktop computers do not
>> seem to have any need for limited range, I personally wouldn't be as
>> arrogant as to say it's never useful. Maybe there are professional
>> video/broadcasting needs that currently can only be realized with
>> proprietary OS/hardware, because Linux just can't do it today?
>>
>> Why would TVs support limited range, if it was never useful? Why would
>> video sources produce limited range if it was always strictly inferior
>> to full range?
>>
>> Even digital image processing algorithms might make use of
>> out-of-unit-range values, not just analog circuitry for overshoot.
>>
>> But no, I can't give a real example, just speculation. Hence it's fine
>> by me to discard limited range processing for now. Still, what I
>> explain below would allow limited range processing without any extra
>> complexity by making the KMS color pipeline better defined and less
>> limiting for userspace.
> 
> AIUI limited range comes from the analogue world, or possibly creative
> (film/TV) world, hence being used on Consumer devices rather than IT
> ones (CTA and CEA modes vs VESA and DMT modes).
> 
> YCbCr output from video codecs typically uses a range of 16-235,
> therefore a media player wanting to pass the decoded video out to the
> display exactly as-is needs to be able to signal that to the display
> for it to be interpreted correctly.
> HDMI extended DVI. I believe both YCbCr support and range control were
> added to the HDMI spec at the same time, presumably to allow for this
> use case. Limited range RGB seems to be a bit of a quirk though.
> 
> Just to be annoying, JPEG uses full range YCbCr.
> 
>>>> How would composition of multiple DRM planes work if some are limited
>>>> range and some are full but you want limited range output? Your
>>>> hardware needs to have CSC matrices to convert full range down to
>>>> limited range, and know that you want to use them to effectively
>>>> compose to limited range.
>>>> In fact you can't currently tell DRM that an RGB plane is limited
>>>> range - the values in enum drm_color_range are
>>>> DRM_COLOR_YCBCR_LIMITED_RANGE and DRM_COLOR_YCBCR_FULL_RANGE [1].
>>
>> Yeah, that's because range conversion has been conflated with
>> YUV-to-RGB conversion, and the result is always full-range RGB in
>> practise, AFAIU. There is no way to feed limited range color into the
>> further color pipeline in KMS, but that's actually a good thing.(*)
>>
>> The following is my opinion of the future, as someone who has been
>> thinking about how to make HDR work on Wayland while allowing the
>> display quality and hardware optimizations that Wayland was designed
>> for:
>>
>>
>> Userspace should not tell KMS about a plane being limited range at all.
>> The reason is the same why userspace should not tell KMS about what
>> colorspace a plane is in.
>>
>> Instead, userspace wants to program specific mathematical operations
>> into KMS hardware without any associated or implied semantics. It's
>> just math. The actual semantics have been worked out by userspace
>> before-hand. This allows to use the KMS hardware to its fullest effect,
>> even for things the hardware or KMS UAPI designers did not anticipate.
>>
>> IMO, framebuffers and KMS planes should ultimately be in undefined
>> quantization range, undefined color space, and undefined dynamic range.
>> The correct processing of the pixel values is programmed by per-plane
>> KMS properties like CTM, LUT, and more specialized components like
>> quantization range converter or YUV-to-RGB converter (which is just
>> another CTM at a different point, really) where userspace explicitly
>> programs the *operation*, and not the input and output types hoping the
>> driver and hardware does something sensible.
> 
> How do you describe the functionality available on constrained
> hardware that has fixed matrices for YUV to RGB conversions using the
> normal BT601 and 709?
> Or hardware that has no per plane matrix for RGB? (I believe vc4 fits
> into this category).
> 

Thanks for bringing this up. This is one of the big challenges I
have when thinking about a generic DRM/KMS HDR API. Compositor devs
would like an API that simply programs operations but the HW designs
in the wild often don't operate on that level. They're designed for
specific use-cases. At times the HW designers will go for a generic
solution to satisfy the range of desired use-cases, other times they
might opt for hard-coding certain conversion.

When designing an API of "operations" there is a real danger such
and API won't map to a lot of HW or introduce a lot of complexity
into compositor backends.

Harry

> I'd also propose that you need a load of helpers so that the "normal"
> use cases of eg BT601 YCbCr to the default composition space is
> handled for simply. Otherwise the enforced complexity to userspace has
> just exploded.
> 
> Or seeing as properties like COLOR_ENCODING and COLOR_RANGE already
> exist in the UAPI, add a "custom" mode to those that will enable all
> your other magic properties.
> 
>> In that design, there is no problem at all to blend multiple planes of
>> differing quantization ranges together. Userspace first chooses the
>> blending space, a radiometrically linear RGB limited range BT.709 space
>> for example, and then programs each plane to produce exactly that. Then
>> CRTC properties are programmed to produce the desired type of output
>> signal. Finally, connector properties are programmed to send the
>> appropriate metadata to the sink. Of course, userspace takes the sink
>> capabilities into account before deciding all this.
>>
>> The thing KMS UAPI is missing are the per-plane properties.
> 
> And hardware support on many platforms.
> I've just checked, and vc4 always composes to RGB. Things like YCbCr
> for HDMI are handled in the HDMI tx block. How do we tell userspace
> that it has no choice over the blending space?
> 
> If you're trying to make things totally comprehensive, please don't
> miss out chroma-siting as that is another property that is missing
> from KMS for YCbCr planes.
> MPEG-2, MPEG-4 and H264 differ from JPEG and MPEG-1 in default
> chroma-siting, and HEVC differs again.
> 
> Conversion of HDR to/from SDR is going to be an interesting problem on
> many platforms. I won't claim enough knowledge on the subject, but
> obviously there needs to be a choice made over which mode composition
> should happen in, and other planes will need to be converted. Is that
> conversion going to be totally generic?
> 
> 
> Lots of questions posed by this discussion, but I'm not sure that they
> are specifically relevant to HDMI quantization ranges at this stage.
> All RGB buffers should be full range, and full/limited range
> conversion should be controlled via a similar mechanism to "Broadcast
> RGB" but in the KMS core.
> 
> Checking drm_hdmi_avi_infoframe_quant_range(), it already does the
> correct thing with regard to the EDID VCD block and signalling the
> quantization range. The implementation of range choice on i915 (and
> vendor vc4 tree) could be improved to also check
> display_info->rgb_quant_range_selectable and choose FULL even for CEA
> modes if the display allows it, but that may expose more compatibility
> issues with monitors where the EDID is a little iffy.
> 
> Cheers
>   Dave
> 
>> (*) The reason it is a good thing that one cannot have limited range
>> framebuffers is that it would raise problems on how to handle pixel
>> values outside of the nominal range, that is, the sub-black and
>> super-white channel values. The immediate problem is that LUT stages
>> need normalized input and they cannot extrapolate. So if nominal
>> quantization range is normalized to 0.0-1.0 for LUT input, sub-black
>> would be negative values and super-white would be greater than 1.0
>> values, which a LUT cannot sensibly handle. That makes the whole
>> concept of limited range problematic in the color pipeline. But, if the
>> color pipeline elements like LUTs are defined *as if* the data was
>> always full range, it becomes well-defined and useful how the elements
>> work, and userspace can produce a proper programming that is guaranteed
>> to work.
>>
>> By completely removing the concept of quantization range and its
>> "automatic" handling from the KMS color pipeline and adding processing
>> elements to do scaling+offset at suitable stages, we gain the ability
>> to accept, process, blend, and produce pixels in any quantization
>> range, color space or dynamic range at will.
>>
>> Another thing such an approach solves is how to interpret
>> floating-point pixel data which can naturally represent
>> out-of-unit-range values.
>>
>>
>> Thanks,
>> pq
>>
>>>> Cheers.
>>>>   Dave
>>>>
>>>> [1] https://elixir.bootlin.com/linux/latest/source/include/drm/drm_color_mgmt.h#L84>>>>> [2] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_edid.c#L6756>>>>> [3] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_edid.c#L5642>>>>>
>>>
>>

Re: The state of Quantization Range handling

[Pekka Paalanen]

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

On Fri, 18 Nov 2022 15:53:29 +0000
Dave Stevenson <dave.stevenson@raspberrypi.com> wrote:

> Hi Pekka
> 
> On Fri, 18 Nov 2022 at 10:15, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > On Thu, 17 Nov 2022 22:13:26 +0100
> > Sebastian Wick <sebastian.wick@redhat.com> wrote:
> >  
> > > Hi Dave,
> > >
> > > I noticed that I didn't get the Broadcast RGB property thanks to you
> > > (more below)
> > >
> > > On Tue, Nov 15, 2022 at 2:16 PM Dave Stevenson
> > > <dave.stevenson@raspberrypi.com> wrote:  
> > > >
> > > > Hi Sebastian
> > > >
> > > > Thanks for starting the conversation - it's stalled a number of times
> > > > previously.
> > > >
> > > > On Mon, 14 Nov 2022 at 23:12, Sebastian Wick <sebastian.wick@redhat.com> wrote:  
> > > > >
> > > > > There are still regular bug reports about monitors (sinks) and sources
> > > > > disagreeing about the quantization range of the pixel data. In
> > > > > particular sources sending full range data when the sink expects
> > > > > limited range. From a user space perspective, this is all hidden in
> > > > > the kernel. We send full range data to the kernel and then hope it
> > > > > does the right thing but as the bug reports show: some combinations of
> > > > > displays and drivers result in problems.  
> > > >
> > > > I'll agree that we as Raspberry Pi also get a number of bug reports
> > > > where sinks don't always look at the infoframes and misinterpret the
> > > > data.
> > > >  
> > > > > In general the whole handling of the quantization range on linux is
> > > > > not defined or documented at all. User space sends full range data
> > > > > because that's what seems to work most of the time but technically
> > > > > this is all undefined and user space can not fix those issues. Some
> > > > > compositors have resorted to giving users the option to choose the
> > > > > quantization range but this really should only be necessary for
> > > > > straight up broken hardware.  
> > > >
> > > > Wowsers! Making userspace worry about limited range data would be a
> > > > very weird decision in my view, so compositors should always deal in
> > > > full range data.  
> > >
> > > Making this a user space problem is IMO the ideal way to deal with it
> > > but that's a bit harder to do (I'll answer that in the reply to
> > > Pekka). So let's just assume we all agree that user space only deals
> > > with full range data.  
> >
> > Limited range was invented for some reason, so it must have some use
> > somewhere, at least in the past. Maybe it was needed to calibrate mixed
> > digital/analog video processing chains with test images that needed to
> > contain sub-blacks and super-whites, to make sure that sub-blacks come
> > out as the nominal black etc. Just because desktop computers do not
> > seem to have any need for limited range, I personally wouldn't be as
> > arrogant as to say it's never useful. Maybe there are professional
> > video/broadcasting needs that currently can only be realized with
> > proprietary OS/hardware, because Linux just can't do it today?
> >
> > Why would TVs support limited range, if it was never useful? Why would
> > video sources produce limited range if it was always strictly inferior
> > to full range?
> >
> > Even digital image processing algorithms might make use of
> > out-of-unit-range values, not just analog circuitry for overshoot.
> >
> > But no, I can't give a real example, just speculation. Hence it's fine
> > by me to discard limited range processing for now. Still, what I
> > explain below would allow limited range processing without any extra
> > complexity by making the KMS color pipeline better defined and less
> > limiting for userspace.  
> 
> AIUI limited range comes from the analogue world, or possibly creative
> (film/TV) world, hence being used on Consumer devices rather than IT
> ones (CTA and CEA modes vs VESA and DMT modes).
> 
> YCbCr output from video codecs typically uses a range of 16-235,
> therefore a media player wanting to pass the decoded video out to the
> display exactly as-is needs to be able to signal that to the display
> for it to be interpreted correctly.
> 
> HDMI extended DVI. I believe both YCbCr support and range control were
> added to the HDMI spec at the same time, presumably to allow for this
> use case. Limited range RGB seems to be a bit of a quirk though.
> 
> Just to be annoying, JPEG uses full range YCbCr.
> 
> > > > How would composition of multiple DRM planes work if some are limited
> > > > range and some are full but you want limited range output? Your
> > > > hardware needs to have CSC matrices to convert full range down to
> > > > limited range, and know that you want to use them to effectively
> > > > compose to limited range.
> > > > In fact you can't currently tell DRM that an RGB plane is limited
> > > > range - the values in enum drm_color_range are
> > > > DRM_COLOR_YCBCR_LIMITED_RANGE and DRM_COLOR_YCBCR_FULL_RANGE [1].  
> >
> > Yeah, that's because range conversion has been conflated with
> > YUV-to-RGB conversion, and the result is always full-range RGB in
> > practise, AFAIU. There is no way to feed limited range color into the
> > further color pipeline in KMS, but that's actually a good thing.(*)
> >
> > The following is my opinion of the future, as someone who has been
> > thinking about how to make HDR work on Wayland while allowing the
> > display quality and hardware optimizations that Wayland was designed
> > for:
> >
> >
> > Userspace should not tell KMS about a plane being limited range at all.
> > The reason is the same why userspace should not tell KMS about what
> > colorspace a plane is in.
> >
> > Instead, userspace wants to program specific mathematical operations
> > into KMS hardware without any associated or implied semantics. It's
> > just math. The actual semantics have been worked out by userspace
> > before-hand. This allows to use the KMS hardware to its fullest effect,
> > even for things the hardware or KMS UAPI designers did not anticipate.
> >
> > IMO, framebuffers and KMS planes should ultimately be in undefined
> > quantization range, undefined color space, and undefined dynamic range.
> > The correct processing of the pixel values is programmed by per-plane
> > KMS properties like CTM, LUT, and more specialized components like
> > quantization range converter or YUV-to-RGB converter (which is just
> > another CTM at a different point, really) where userspace explicitly
> > programs the *operation*, and not the input and output types hoping the
> > driver and hardware does something sensible.  
> 
> How do you describe the functionality available on constrained
> hardware that has fixed matrices for YUV to RGB conversions using the
> normal BT601 and 709?
> Or hardware that has no per plane matrix for RGB? (I believe vc4 fits
> into this category).

Hi Dave,

enum property.

If they are fixed conversion matrices, each enum value can either refer
to a standard specifying the matrix or point to a DRM blob containing
the fixed matrix for userspace to take a look.

The same with 1D LUTs.

If hardware supports both arbitrary matrix and fixed matrices, one of
the enum values could e.g. be "use arbitrary matrix" and have another
KMS blob property for the matrix data.

The important thing is that the properties fully define the operation
done by the hardware, and do not depend on other things like is the
input image full or limited range or what color space it has.

So for quantization range operations applied to pixels, you would have
enum values:
- auto (driver-specific heuristics for backwards compatibility)
- identity (pass-through)
- limited-to-full with clipping
- full-to-limited

Compare that to enum values:
- auto (as above)
- force limited
- force full

These latter enum values do not encode the operation. The driver will
decide on what operation it does depending on what it *thinks* the
input image description is. This is indirect and error-prone. It can
also be not well-defined. We need well-defined operations, so that we
can do exactly the same in a rendering API (GL/Vulkan) in cases where
for some reason we cannot use KMS for it. For desktop window systems,
such fallbacks are very often needed. For set-top-box or other very
restricted use cases the fallbacks may be never needed.

Mind, that this quantization range pixel value operation property would
be orthogonal to the quantization range metadata sent to a sink, if the
sink can even accept such metadata.

> 
> I'd also propose that you need a load of helpers so that the "normal"
> use cases of eg BT601 YCbCr to the default composition space is
> handled for simply. Otherwise the enforced complexity to userspace has
> just exploded.

I think it is not kernel UAPIs position to offer layered APIs for easy
use for simple cases. That's the job for userspace libraries.

Unfortunately, we also cannot take existing KMS properties away,
because it may regress (old) userspace.

> Or seeing as properties like COLOR_ENCODING and COLOR_RANGE already
> exist in the UAPI, add a "custom" mode to those that will enable all
> your other magic properties.

My explicit desire is to take all magic out of KMS.

Yes, something like that is probably necessary. Or a DRM client cap.
But I think all this is about some new UAPI. I think Sebastian wanted
just to have the existing UAPI spelled out and clarified what it means
and how it works, and that's fine. I'm just looking much further,
because I think the old design is a dead end and that people should
understand why while we are talking about it.

> > In that design, there is no problem at all to blend multiple planes of
> > differing quantization ranges together. Userspace first chooses the
> > blending space, a radiometrically linear RGB limited range BT.709 space
> > for example, and then programs each plane to produce exactly that. Then
> > CRTC properties are programmed to produce the desired type of output
> > signal. Finally, connector properties are programmed to send the
> > appropriate metadata to the sink. Of course, userspace takes the sink
> > capabilities into account before deciding all this.
> >
> > The thing KMS UAPI is missing are the per-plane properties.  
> 
> And hardware support on many platforms.
> I've just checked, and vc4 always composes to RGB.

That is very natural, because for alpha-blending to make sense, you
pretty much must have an additive color space. YCbCR is definitely not
one. Strictly speaking electrically encoded RGB is not one either, but
still people use it, and want it because they have always used it (it
won't work for HDR though). Optically encoded RGB is the right class of
color spaces for alpha-blending.

> Things like YCbCr
> for HDMI are handled in the HDMI tx block. How do we tell userspace
> that it has no choice over the blending space?

You tell userspace what your color pipeline looks like, and userspace
fits what it wants into it, or uses a rendering API as a fallback.

It's not as dire as it may sound, because as I said, (optical) RGB is
the only class of blending spaces that makes general sense.

Then again, there is no need for the display driver to even know what
the blending space is. It simply carries out the operations that
userspace has chosen from the set of operations the driver claims to
implement.

> If you're trying to make things totally comprehensive, please don't
> miss out chroma-siting as that is another property that is missing
> from KMS for YCbCr planes.

Of course, we do need that.

Lack of such property will prevent some display servers from using the
KMS planes for YCbCr when they become more strict about image quality.

> MPEG-2, MPEG-4 and H264 differ from JPEG and MPEG-1 in default
> chroma-siting, and HEVC differs again.
> 
> Conversion of HDR to/from SDR is going to be an interesting problem on
> many platforms. I won't claim enough knowledge on the subject, but
> obviously there needs to be a choice made over which mode composition
> should happen in, and other planes will need to be converted. Is that
> conversion going to be totally generic?

We will see. I do doubt the hardware existing today will satisfy the
most demanding use cases, no matter how the UAPI is designed.

I think those conversions are also still much a research question,
which means generic programmable hardware has an edge as people can
experiment and choose their conversion methods more freely.

> Lots of questions posed by this discussion, but I'm not sure that they
> are specifically relevant to HDMI quantization ranges at this stage.

Right.

Thanks,
pq


> All RGB buffers should be full range, and full/limited range
> conversion should be controlled via a similar mechanism to "Broadcast
> RGB" but in the KMS core.
> 
> Checking drm_hdmi_avi_infoframe_quant_range(), it already does the
> correct thing with regard to the EDID VCD block and signalling the
> quantization range. The implementation of range choice on i915 (and
> vendor vc4 tree) could be improved to also check
> display_info->rgb_quant_range_selectable and choose FULL even for CEA
> modes if the display allows it, but that may expose more compatibility
> issues with monitors where the EDID is a little iffy.
> 
> Cheers
>   Dave

...

> > > > Cheers.
> > > >   Dave
> > > >
> > > > [1] https://elixir.bootlin.com/linux/latest/source/include/drm/drm_color_mgmt.h#L84
> > > > [2] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_edid.c#L6756
> > > > [3] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_edid.c#L5642
> > > >  
> > >  
> >  


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