linux-kernel - Re: [PATCH v2 5/8] drm/rockchip: vop2: Enforce AFBC source alignment in plane

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: <CAPj87rN19nQcFT_u8WyNO6a+2AbAp2hBG7ARbWoJ8-jwO3yGfA@mail.gmail.com>
Date: Tue, 20 Jan 2026 10:35:38 +0000
From: Daniel Stone <daniel@...ishbar.org>
To: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Cc: Sandy Huang <hjc@...k-chips.com>, Heiko Stübner <heiko@...ech.de>, 
	Andy Yan <andy.yan@...k-chips.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>, 
	Chaoyi Chen <chaoyi.chen@...k-chips.com>, kernel@...labora.com, 
	dri-devel@...ts.freedesktop.org, linux-arm-kernel@...ts.infradead.org, 
	linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	Daniel Stone <daniels@...labora.com>
Subject: Re: [PATCH v2 5/8] drm/rockchip: vop2: Enforce AFBC source alignment
 in plane_check

Hi all,

On Tue, 9 Dec 2025 at 10:58, Nicolas Frattaroli
<nicolas.frattaroli@...labora.com> wrote:
> In either case, I think adhering to the atomic API to ensure
> artifact-free presentation is more important here than enabling
> a fast-path on RK3568. I do think in most real-world use case
> scenarios, the fallback won't degrade user experience, because
> almost everything performance intensive I can think of (video
> playback, games) will likely already use a plane geometry
> where the width is divisible by 4. 800, 1024, 1280, 1600, 1920,
> 2560, 3840 are all divisible by 4, so a window or full-screen
> playback of common content won't need to fall back to GPU
> compositing.

That's exactly it. Changing userspace's request may result in
unpleasant visual artifacts and other unwanted effects. If userspace
wants to always hit a fast path, then it will need some kind of
hardware awareness to do something different here. The patch series
pointed out gives userspace a good way to figure this out.

With my Weston maintainer hat on, I'd take a patch to
weston-simple-egl to allow it to use a different size with
command-line arguments if you'd like that for easier testing. (Fun
fact: it was specifically made 250x250 to discover issues such as
this, which wouldn't be uncovered by something that's aligned to a
generous power of two.)

Cheers,
Daniel