linux-kernel - Re: [PATCH RFC 1/5] drm: Support post-blend color pipeline API

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>] [day] [month] [year] [list]

Message-ID: <CAPj87rMHP_np_9vtnyJ_NU4S3W09DoMRrLPps-33hTngdLyKCw@mail.gmail.com>
Date: Tue, 30 Sep 2025 14:20:09 +0200
From: Daniel Stone <daniel@...ishbar.org>
To: Sebastian Wick <sebastian@...astianwick.net>
Cc: Nícolas F. R. A. Prado <nfraprado@...labora.com>, 
	Xaver Hugl <xaver.hugl@...il.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	Chun-Kuang Hu <chunkuang.hu@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>, 
	Matthias Brugger <matthias.bgg@...il.com>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Alex Hung <alex.hung@....com>, 
	wayland-devel@...ts.freedesktop.org, harry.wentland@....com, leo.liu@....com, 
	ville.syrjala@...ux.intel.com, pekka.paalanen@...labora.com, mwen@...lia.com, 
	jadahl@...hat.com, sebastian.wick@...hat.com, shashank.sharma@....com, 
	agoins@...dia.com, joshua@...ggi.es, mdaenzer@...hat.com, aleixpol@....org, 
	victoria@...tem76.com, uma.shankar@...el.com, quic_naseer@...cinc.com, 
	quic_cbraga@...cinc.com, quic_abhinavk@...cinc.com, marcan@...can.st, 
	Liviu.Dudau@....com, sashamcintosh@...gle.com, 
	chaitanya.kumar.borah@...el.com, louis.chauvet@...tlin.com, mcanal@...lia.com, 
	kernel@...labora.com, daniels@...labora.com, dri-devel@...ts.freedesktop.org, 
	linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org, 
	linux-arm-kernel@...ts.infradead.org, Simona Vetter <simona.vetter@...ll.ch>
Subject: Re: [PATCH RFC 1/5] drm: Support post-blend color pipeline API

Hi,

On Fri, 26 Sept 2025 at 15:45, Sebastian Wick
<sebastian@...astianwick.net> wrote:
> So I'm going to argue that making the properties read-only or read-write is useless.
>
> The only case where knowing the color pipeline of the previous user would be useful is if you want to re-use the framebuffer of said user. Otherwise, the color pipeline and the generated framebuffer have to somehow just match to produce the desired output and that does not require any previous state, making the legacy properties useless.

I don't think it's useless; if nothing else, drm_info is a thing and
having it work is nice.

> If we genuinely believe that this is something to be supported, then my question is why the new color pipeline should not be able to accurate reflect the state of the previous user, even if they used the legacy props?

That's reasonable. My hunch was that it would be too much code in the
kernel to essentially just do format reinterpretation on userspace's
behalf.

> The hardware was able to get into some state based on the legacy props, so it will be able to get into the same state with the color pipeline props; it's "just" a matter of exposing the right pipeline.
>
> If we are not able to accurate reflect the previous state with the pipeline props, then use space will see inconsistent state between the legacy and color pipeline props. Which state is the right one? We cannot know. The previous user could have used either one. So having the legacy props does not help because we don't know if we should use them or the pipeline state.
>
> So, I would argue that we should *remove* the legacy props if DRM_CLIENT_CAP_POST_BLEND_COLOR_PIPELINE is set. If the handover is relevant for a driver, they should ensure the legacy props state translates to the correct color pipeline state.

FWIW, the usecase I can see in mind would be doing a fade-style
transition between the old and new clients. But I don't really care
too strongly about it to be honest; I mostly care about having
drm_info work because it's a super-useful tool.

Cheers,
Daniel