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

[Maxime Ripard <mripard@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]

On Wed, Aug 27, 2025 at 11:39:25AM +0100, 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.

Oh, yeah, definitely.

But bringing the big guns and the requirements we have for those to
address the point initially discussed by the gitlab issues seems like
biting off more than they can chew.

Even more so since whatever uapi we come up with would still depend on
the EDIDs, and they would still be broken for these monitors.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]