Your message lacks a In-reply-to header, so it broke the thread. You also removed everyone else from Cc, including all lists other than dri-devel.
On Saturday, 16 May 2026 02:17:37 Central European Summer Time TR Reardon wrote: > Hi Nicolas, > > Apologies for surfacing this on v14 - the feedback is overdue and I should > have raised it months ago. > I am writing from the perspective of a developer of media player software for > Linux. > > In the kerneldoc the patch adds for DRM_CONNECTOR_COLOR_FORMAT_RGB444: > > The quantization range depends on the value of the "Broadcast RGB" > property if it is present on the connector. > > I want to raise a related problem that I think is in scope to solve as part > of this series: limited-range RGB (e.g. 16-235 out of > 0-255) is broken in the DRM pipeline. That does not appear to be in-scope for this series. This series is about allowing userspace to choose RGB vs YUV and the YUV subsampling to use. As a point of comparison, the color format property also says nothing about the wire's bit depth, even though this is something that userspace may want to control; there's a separate property for it. The reason why chroma subsampling + RGB vs. YUV is in the same property here is that subsampled RGB wouldn't make sense, and the two things also aren't talked about separately in any of the display protocols from what I can tell. I believe this is part of why it seems attractive to tack more bits of the output parameter space onto this property, even though an additional property could communicate that as well. > > 'Broadcast RGB' couples three semantically independent things into a single > enum: > > 1. How the framebuffer is encoded (full 0-255 or limited 16-235) > 2. Whether the encoder-side pipe applies the 219/255 + 16/255 CSC > compression > 3. What the AVI Q bit (HDMI) or equivalent MSA signal (DP) declares to the > sink > > The three supported values bake assumptions about all three: > > Full FB is 0-255, no pipe CSC, signals FULL > Limited FB is 0-255, pipe compresses to 16-235, signals LIMITED > Automatic Per CEA-861-E section 5.1: CE-mode VICs behave as Limited, > IT modes as Full > > None expresses what userspace actually needs when it has produced > limited-range content itself: "leave my pixels alone, signal > LIMITED on the wire." The CTM property is not an escape hatch either: the > limited-range CSC has a fixed +16/255 postoff that no > symmetric 3x3 CTM can cancel. I'm not sure if "leave my pixels alone" would be a good design for the uAPI; I think it's much better to tell the kernel *what* your pixels are so that it can leave them alone when it doesn't need to touch them. Specifically, the case you're talking about appears to be that the kernel does not realise that the contents you're submitting from userspace is already limited range, so it would go through double-conversion if "Broadcast RGB" was set. > I want to emphasize: this means Linux is incapable of sending SMPTE-standard > RGB over HDMI or DP. The content is either corrupted > by the kernel's compression stage or the wire signaling is wrong - do one or > the other, not both. This is a long-standing gap > that I am hoping can be addressed in scope of this series. > > Proposal: rather than touching 'Broadcast RGB' (which keeps its current > behavior unchanged), add a new value to the color format > enum that explicitly declares limited-range RGB content on the wire: > > DRM_CONNECTOR_COLOR_FORMAT_AUTO > DRM_CONNECTOR_COLOR_FORMAT_RGB444 (existing - full 0-255, current > semantics) > DRM_CONNECTOR_COLOR_FORMAT_RGB444_LIMITED (new - declares 16-235 RGB on > the wire) > DRM_CONNECTOR_COLOR_FORMAT_YCBCR444 > DRM_CONNECTOR_COLOR_FORMAT_YCBCR422 > DRM_CONNECTOR_COLOR_FORMAT_YCBCR420 > > Semantics of the new value: > > - It is purely a wire-side declaration: the AVI Q bit is signaled as LIMITED, > and the kernel makes no other change to the > pipeline. > - It does NOT alter what 'Broadcast RGB' does. The pipe-side CSC behavior > remains controlled by 'Broadcast RGB' exactly as today. > - Userspace that wants pass-through limited-range RGB on the wire sets > 'Broadcast RGB' = Full (so the kernel does no in-pipe range > conversion) AND color format = RGB444_LIMITED (so the wire signals LIMITED). > The two properties are orthogonal. > - Userspace that wants the legacy "kernel compresses and signals" path > continues to use 'Broadcast RGB' = Limited and leaves color > format at AUTO or RGB444. > - If both 'Broadcast RGB' and 'color format' would request LIMITED for the Q > bit, that is just redundant agreement, not a conflict. There is nothing in this proposal that couldn't be added later, if you wanted to do this. I don't agree with the concept of making the color format encode more than what it currently encodes. I do think the better solution for this issue is to extend the Broadcast RGB property for your purposes, e.g. have a "Limited Passthrough" enum value for Broadcast RGB that tells the kernel to assume the input is already limited range. Alternatively, add a new property that describes what range the input is, and the kernel can then choose to not convert on the basis of that. > This preserves the existing design assumption that bare RGB means 0-255 full > range and that 'Broadcast RGB' is the knob for > kernel-side range conversion. The new value adds an explicit way to declare > limited-range content on the wire without taking on > the in-pipe CSC as a side effect. Userspace that produces limited-range RGB > itself - either because that is what its content > already is, or because it wants to take responsibility for its own pixel > encoding - now has a lossless way to express that intent. > > Thanks, > > > +Reardon I won't work on fixing the issue you brought up here, but you can send your own follow-up series once color format has been merged to extend it in this way. I suspect however that maintainers won't be fond of this approach. I believe extending Broadcast RGB for your purposes may be the better option, though I didn't look into how the colorspace property would interact with this as well. Kind regards, Nicolas Frattaroli
