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: <CAPj87rMDj-3ohEtXQYy25Rp0zNtZxQxS4Rmd-akgx9kkvB4Ysw@mail.gmail.com>
Date: Wed, 27 Aug 2025 12:36:53 +0100
From: Daniel Stone <daniel@...ishbar.org>
To: Maxime Ripard <mripard@...nel.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

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?

Cheers,
Daniel