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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250827-skilled-jasper-angelfish-853f26@houat>
Date: Wed, 27 Aug 2025 13:40:53 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Daniel Stone <daniel@...ishbar.org>
Cc: Shengyu Qu <wiagn233@...look.com>, 
	Marius Vlad <marius.vlad@...labora.com>, alexander.deucher@....com, christian.koenig@....com, 
	airlied@...il.com, simona@...ll.ch, harry.wentland@....com, sunpeng.li@....com, 
	siqueira@...lia.com, maarten.lankhorst@...ux.intel.com, tzimmermann@...e.de, 
	contact@...aelrc.com, lijo.lazar@....com, jesse.zhang@....com, tim.huang@....com, 
	dark_sylinc@...oo.com.ar, mario.limonciello@....com, alex.hung@....com, 
	aurabindo.pillai@....com, sunil.khatri@....com, chiahsuan.chung@....com, mwen@...lia.com, 
	Roman.Li@....com, Wayne.Lin@....com, dominik.kaszewski@....com, alvin.lee2@....com, 
	Aric.Cyr@....com, Austin.Zheng@....com, Sung.Lee@....com, PeiChen.Huang@....com, 
	dillon.varone@....com, Richard.Chiang@....com, ryanseto@....com, linux@...blig.org, 
	haoping.liu@....com, Relja.Vojvodic@....com, Yihan.Zhu@....com, Samson.Tam@....com, 
	amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, 
	wayland-devel@...ts.freedesktop.org
Subject: Re: [PATCH v2 0/2] Add "pixel_encoding" to switch between RGB & YUV
 color modes

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@...nel.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

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)