Hi there,

On Thu, 26 Mar 2026 at 12:44, Nicolas Frattaroli
[off-list ref] wrote:

On Wednesday, 25 March 2026 12:03:07 Central European Standard Time Ville Syrjälä wrote:

quoted

But I'm not really concerned about documenting struct members.
What I'm talking about is the *uapi* docs. Surely userspace
will want to know what the new property actually does so the
uapi needs to be documented properly. And down the line some
new driver might also implement the wrong behaviour if there
is no clear specification.

So I'm thinking (or perhaps hoping) the rule might be something like:
- YCbCr limited range
- RGB full range if "Broadcast RGB" property is not present
- RGB full or limited range based on the "Broadcast RGB" property
  if it's present

I think the "Broadcast RGB" property itself might also be lacking
proper uapi docs, so that may need to be remedied as well.

Alright, so in v12 I'll do the following:

- Add a line to all YCBCR connector formats that specifies they're
  limited range as long as Broadcast RGB is limited. Whether it's limited
  range when Broadcast RGB is full is purposefully left undefined.
  In the future, we can expand this to state they're limited range by
  default unless some other property is set. If we're not re-using
  Broadcast RGB for that, this will work out fine, because users who
  don't know about the eventual new property won't have this behaviour
  changed. If we do re-use "Broadcast RGB" for that, then only users
  relying on things we explicitly left undefined will get surprise
  full range YCBCR.
- Add a line to the RGB connector format that specifies its range
  depends on the "Broadcast RGB" property

This is a bit of a mess, because it's entirely reasonable that a
future YCBCR range property would want to default to full range
so that users get the most color out of their monitors. But with
this description of the connector color formats, we can't do that.

If there are alternate suggestions, I'm open for them. We can't
really rename "Broadcast RGB" but if I had a time machine, that'd
be my first choice.

'Broadcast RGB' isn't what you want even if it could handle YUV, since
it also sets up colour transforms to modify the data ... so we need a
separate, orthogonal, property which only affects the HDMI infoframe,
rather than applying any transforms.

Cheers,
Daniel