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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAPj87rPhK+E2FP62fnNxFySDOkqqKxo_oa94i7DR3_6a1j1o1A@mail.gmail.com>
Date: Wed, 27 Aug 2025 11:39:25 +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 10:41, Maxime Ripard <mripard@...nel.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.

Cheers,
Daniel