Hi there, On Thu, 26 Mar 2026 at 12:44, Nicolas Frattaroli <[email protected]> wrote: > On Wednesday, 25 March 2026 12:03:07 Central European Standard Time Ville > Syrjälä wrote: > > 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
