On 3/26/26 13:02, Nicolas Frattaroli wrote: > On Thursday, 26 March 2026 12:16:12 Central European Standard Time Dave > Stevenson wrote: >> On Wed, 25 Mar 2026 at 13:43, Ville Syrjälä >> <[email protected]> wrote: >>> On Wed, Mar 25, 2026 at 12:49:19PM +0000, Dave Stevenson wrote: >>>> On Tue, 24 Mar 2026 at 16:02, Nicolas Frattaroli >>>> <[email protected]> wrote: >>>>> >>>>> +/** >>>>> + * enum drm_connector_color_format - Connector Color Format Request >>>>> + * >>>>> + * This enum, unlike &enum drm_output_color_format, is used to specify >>>>> requests >>>>> + * for a specific color format on a connector through the DRM "color >>>>> format" >>>>> + * property. The difference is that it has an "AUTO" value to specify >>>>> that >>>>> + * no specific choice has been made. >>>>> + */ >>>>> +enum drm_connector_color_format { >>>>> + /** >>>>> + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display >>>>> protocol >>>>> + * helpers should pick a suitable color format. All >>>>> implementations of a >>>>> + * specific display protocol must behave the same way with >>>>> "AUTO", but >>>>> + * different display protocols do not necessarily have the same >>>>> "AUTO" >>>>> + * semantics. >>>>> + * >>>>> + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if >>>>> the >>>>> + * bandwidth required for full-scale RGB is not available, or the >>>>> mode >>>>> + * is YCbCr 4:2:0-only, as long as the mode and output both >>>>> support >>>>> + * YCbCr 4:2:0. >>>> >>>> Is there a reason you propose dropping back to YCbCr 4:2:0 without >>>> trying YCbCr 4:2:2 first? Minimising the subsampling is surely >>>> beneficial, and vc4 for one can do 4:2:2 but not 4:2:0. >>> >>> On HDMI 4:2:2 is always 12bpc, so it doesn't save any bandwidth >>> compared to 8bpc 4:4:4. >> >> It does save bandwidth against 10 or 12bpc RGB 4:4:4. >> >> Or is the implication that max_bpc = 12 and >> DRM_CONNECTOR_COLOR_FORMAT_AUTO should drop bpc down to 8 and select >> RGB in preference to selecting 4:2:2? > > Yes. Some people consider max-bpc to not be a legitimate way of requesting > an actual bpc, and don't think drivers will choose the highest bpc <= max-bpc, > and instead may negotiate a fantasy number anywhere below or equal to max-bpc.
Ridiculing others like this for disagreeing with you is uncalled for. Is there any evidence for your claim that the driver must always use the highest possible bpc <= max-bpc? > Of course this logic could be done in userspace which knows whether the > less chroma for more bit depth trade-off is worth it, but userspace does > not know the negotiated link bpc, and my attempts at adding a property for > it are being blocked. Assuming you're referring to the concerns I raised there, I don't have the power or intent to block it. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
