Re: [PATCH v2 0/2] Add "pixel_encoding" to switch between RGB & YUV color modes

["Sebastian Wick" <sebastian.wick@redhat.com>]

On Wed Aug 27, 2025 at 1:08 PM CEST, Sebastian Wick wrote:
> On Wed Aug 27, 2025 at 12:39 PM CEST, Daniel Stone wrote:
>> Hey,
>>
>> On Wed, 27 Aug 2025 at 10:41, Maxime Ripard <mripard@kernel.org> wrote:
>>> On Wed, Aug 27, 2025 at 12:26:56AM +0800, Shengyu Qu wrote:
>>> > 1.Can you send patch with only i915/amdgpu first? It's a long-needed feature
>>> > to deal with some monitors/TVs with broken EDID.
>>>
>>> If it's to workaround broken monitors, then it's really not something we
>>> should be doing using a property.
>>>
>>> Most likely, those monitors don't support YUV* output and will just need
>>> to be forced to RGB, so it's not something that the user (or the
>>> compositor, really) has to care about.
>>>
>>> And it would be broken with every driver, not just i915 and amdgpu.
>>>
>>> We already have some quirks infrastructure in place, the only thing we
>>> need to do is create an EDID_QUIRK_NO_$FORMAT, clear
>>> drm_display_info->color_formats based on it, and you're done. No uapi to
>>> agree upon, support, test, and it works with every driver.
>>
>> There are other reasons to have uAPI though ...
>>
>> One is because you really care about the colour properties, and you'd
>> rather have better fidelity than anything else, even if it means some
>> modes are unusable.
>>
>> Another is for situations which static quirks can't handle. If you
>> want to keep headroom on the link (either to free up bandwidth for
>> other uses), or you accidentally bought a super-long cable so have a
>> flaky link, you might well want to force it to use lower fidelity so
>> you can negotiate a lower link rate.
>>
>> I'm all for just dtrt automatically, but there are definitely reasons
>> to expose it to userspace regardless.
>
> Yes!
>
> Broadcast RGB is a property that only works as a workaround for broken
> monitors. If user space sets it to a value other than auto, even after
> first checking the EDID if the sink supports it, we don't know if the
> kernel just changes the values, or also sends the InfoFrame (or the DP
> equivalent).
>
> So even if the new property was just for broken sinks, we already have a
> similar case, and it makes sense: If the EDID fails to read properly, or
> the display has no EDID, the kernel can't really identify the thing, so
> you need something in user space anyway.
>
> Even for quirks where you can identify something, user space is a better
> fit because we can update things faster. This is one of the goals of
> libdisplay-info anyway.
>
> Either way, like Daniel said, this *is* useful for other reasons. We
> want to be able to switch between quality and bandwidth.

Daniel suggested in the other thread that the last part of the transform
should be done via a connector property. I'll take that at face value
beause I really don't really know what hardware does. What's important
then is however to make it absolutely clear what the transform looks
like exactly to user space, to make it possible to program the CRTC
color pipeline to produce the correct values.

>
>> Cheers,
>> Daniel