linux-kernel - Re: [PATCH RFC 0/6] AFBC fixes for MediaTek DRM

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

Message-ID: <cc128facb246d89408cf46aa7c9e250c56900940.camel@collabora.com>
Date: Fri, 09 Jan 2026 15:27:43 -0300
From: Nícolas "F. R. A. Prado" <nfraprado@...labora.com>
To: Chun-Kuang Hu <chunkuang.hu@...nel.org>, Philipp Zabel	
 <p.zabel@...gutronix.de>, David Airlie <airlied@...il.com>, Simona Vetter	
 <simona@...ll.ch>, Matthias Brugger <matthias.bgg@...il.com>, 
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Justin Green <greenjustin@...omium.org>
Cc: kernel@...labora.com, dri-devel@...ts.freedesktop.org, 
	linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, ariel.dalessandro@...labora.com, 
	daniels@...labora.com, Nancy.Lin@...iatek.com, Jason-JH.Lin@...iatek.com
Subject: Re: [PATCH RFC 0/6] AFBC fixes for MediaTek DRM

On Tue, 2025-12-30 at 11:03 -0300, Nícolas F. R. A. Prado wrote:
> This series contains a handful of fixes for AFBC support on the
> MediaTek
> DRM driver so that it can be re-enabled.
> 
> This is sent as an RFC because there are still some issues to work
> out
> before the series can be merged:
> 
> 1. Patch 4, 'drm/mediatek: ovl: Disallow AFBC buffers with width over
>    1920' did not behave well when tested with Weston, so a better
>    solution probably needs to be implemented before this can be
> merged.
> 
> 2. Remaining AFBC issues:
>    
>    a. The first 4 pixel rows are always skipped in the displayed
> output,
>       that is, the first displayed pixel, on the top-left corner,
>       corresponds to 4x0. And below the end of the displayed output,
> the
>       first 4x32 pixels are displayed.
> 
>    b. On some resolutions, there are still artifacts that look like
>       misalignment issues, eg 1024x1080, 1080x1080.
> 
>    c. On some resolutions, no output at all is displayed, eg
> 1920x1080.

I received a suggestion that the Lx_2ND_SUBBUF bit in OVL is not needed
when cropping is not enabled, and that removing it should fix the extra
pixels after the image described in 2.a., and perhaps even fix AFBC not
working with MT8188, though I haven't had time to test it.


-- 
Thanks,

Nícolas