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