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: 2326 bytes --]

On Wed, Aug 27, 2025 at 12:36:53PM +0100, Daniel Stone wrote:
> Hey,
> 
> On Wed, 27 Aug 2025 at 12:21, Maxime Ripard <mripard@kernel.org> wrote:
> > On Wed, Aug 27, 2025 at 11:39:25AM +0100, Daniel Stone wrote:
> > > 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.
> 
> Sounds like we're agreeing with each other then.
> 
> Shengyu's 'I want these broken panels to work' usecase is probably
> best served with an EDID quirk, yeah.
> 
> The reason Marius is working on it is the reasons I said above though
> - some for uses where we'd rather clearly fail out and push an error
> to userspace than continue with visually-degraded output, and some for
> uses where people have bought a too-long cable (or bought a too-short
> one which is now at tension through a 180° bend) so we want to force
> the lowest link rate possible, without dropping to a ridiculously low
> resolution.
> 
> So I don't think these are in tension, and Marius should proceed with
> his work (complete with the proper userspace to back it up), and
> Shengyu should proceed with new in-kernel quirks, which will be
> effective when the properties are set to auto, but hard overridden by
> userspace if it decides otherwise.
> 
> How does that sound?

Like a great plan :)

Maxime

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