From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EB0D3FD3762 for ; Wed, 25 Feb 2026 14:14:06 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4C44E10E88A; Wed, 25 Feb 2026 14:14:06 +0000 (UTC) Received: from cstnet.cn (smtp81.cstnet.cn [159.226.251.81]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3245610E88A for ; Wed, 25 Feb 2026 14:14:05 +0000 (UTC) Received: from edelgard.fodlan.icenowy.me (unknown [112.94.101.233]) by APP-03 (Coremail) with SMTP id rQCowABnhNulA59ptU5PCQ--.33561S2; Wed, 25 Feb 2026 22:13:58 +0800 (CST) Message-ID: <05a4de6326d68fc51f6e4dae9aa24ec56497adf6.camel@iscas.ac.cn> Subject: Re: [PATCH] drm/dumb-buffers: document that it's only for linear FB From: Icenowy Zheng To: Thomas Zimmermann , Maarten Lankhorst , Maxime Ripard , David Airlie , Simona Vetter Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Date: Wed, 25 Feb 2026 22:13:57 +0800 In-Reply-To: <3316784a-d9e4-4199-a32a-44b4d0e7b4c2@suse.de> References: <20260225061315.1003811-1-zhengxingda@iscas.ac.cn> <6515820a-3bb3-4868-9b30-9c1f80709ab2@suse.de> <35fba9692636a2f6ba9fabc8e67f5684a54b17f1.camel@iscas.ac.cn> <131b54f7-a611-4a02-aca8-5613643a6276@suse.de> <80590bdf692add75da321a6fc595012d10192a14.camel@iscas.ac.cn> <3316784a-d9e4-4199-a32a-44b4d0e7b4c2@suse.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 MIME-Version: 1.0 X-CM-TRANSID: rQCowABnhNulA59ptU5PCQ--.33561S2 X-Coremail-Antispam: 1UD129KBjvJXoWxZw1rJrW7uF4UWF13Cw1xZrb_yoWrCFyUpF W3KFW2yrs5Jr1fJr1qqF15JFy3tay7XF4Uur98Jry7XryqyF1xWF48t398uF9rur18GF12 qr1jqryfur1UAaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IE w4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMc vjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCY1x0262kKe7AKxVWUAVWUtwCF04k2 0xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI 8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41l IxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIx AIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2 jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07bYYLPUUUUU= X-Originating-IP: [112.94.101.233] X-CM-SenderInfo: x2kh0wp0lqwv3d6l2u1dvotugofq/ X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" =E5=9C=A8 2026-02-25=E4=B8=89=E7=9A=84 09:34 +0100=EF=BC=8CThomas Zimmerman= n=E5=86=99=E9=81=93=EF=BC=9A > Hi >=20 > Am 25.02.26 um 09:10 schrieb Icenowy Zheng: > > =E5=9C=A8 2026-02-25=E4=B8=89=E7=9A=84 08:47 +0100=EF=BC=8CThomas Zimme= rmann=E5=86=99=E9=81=93=EF=BC=9A > > >=20 > > > Am 25.02.26 um 08:38 schrieb Icenowy Zheng: > > > > =E5=9C=A8 2026-02-25=E4=B8=89=E7=9A=84 08:26 +0100=EF=BC=8CThomas Z= immermann=E5=86=99=E9=81=93=EF=BC=9A > > > > > Hi, > > > > >=20 > > > > > Am 25.02.26 um 07:13 schrieb Icenowy Zheng: > > > > > > The ioctl interfaces for dumb buffers currently only > > > > > > properly > > > > > > support > > > > > > linear buffers. > > > > > >=20 > > > > > > Mention this in the documentation snippet of dumb-buffers > > > > > > source > > > > > > code, > > > > > > which is referenced by drm-kms.rst and will end up in the > > > > > > built > > > > > > kernel > > > > > > documentation. > > > > > >=20 > > > > > > Also mention the existence of current drivers abusing dumb > > > > > > buffers > > > > > > for > > > > > > AFBC to reduce confusion about this. > > > > > >=20 > > > > > > Signed-off-by: Icenowy Zheng > > > > > > --- > > > > > > =C2=A0=C2=A0=C2=A0 drivers/gpu/drm/drm_dumb_buffers.c | 7 +++++= +- > > > > > We documented the meaning of the color bits and the behavior > > > > > of > > > > > the > > > > > dumb-buffer interface at [1]. If anything is missing, it > > > > > should > > > > > be > > > > > added > > > > > there. > > > > Yes, I saw this piece of document; however it's part of the > > > > interface > > > > document instead of a concept document, and the whole existence > > > > of > > > > the > > > What is a concept document? > > Well I am patching this document snippet because it becomes part of > > the > > document at [1] (by being referenced in the .rst file). >=20 > That question was a joke, but also not entirely untrue. >=20 > These overview sections usually introduce the purpose of a module and > give readers a sense of how to use the code; like a tutorial. We > don't=20 > have concept documents. As the concepts keep changing, they'd bitrot=20 > quickly. >=20 > For example, not too long ago we discussed the possibility of a=20 > CREATE_DUMB2 ioctl that would allow for specifying the DRM format=20 > directly. It would also allow formats with multiple planes and=20 > non-linear layouts. My point is that whatever we write here today > could=20 > be obsolete tomorrow. The only stable thing is the user-space > interfaces. >=20 > IMHO if you think the overview should mention the supported formats, > you=20 > should link to the UAPI documentation of the ioctl. If we ever get > that=20 > CREATE2 ioctl, we can refer to this as well. This sounds reasonable. I will reword this to a reference to the UAPI documentation to raise attraction (because otherwise it's not very natrual to consult the UAPI doc, at least for me). Thanks, Icenowy >=20 > Best regards > Thomas >=20 > >=20 > > [1] https://docs.kernel.org/gpu/drm-kms.html#dumb-buffer-objects > >=20 > > > > document snippet I am changing can be considered a duplicate of > > > > the > > > > interface document. > > > >=20 > > > > Thanks > > > > Icenowy > > > >=20 > > > > > Best regards > > > > > Thomas > > > > >=20 > > > > > [1] > > > > > https://elixir.bootlin.com/linux/v6.19/source/include/uapi/drm/dr= m_mode.h#L1200 > > > > >=20 > > > > > > =C2=A0=C2=A0=C2=A0 1 file changed, 6 insertions(+), 1 deletion(= -) > > > > > >=20 > > > > > > diff --git a/drivers/gpu/drm/drm_dumb_buffers.c > > > > > > b/drivers/gpu/drm/drm_dumb_buffers.c > > > > > > index e2b62e5fb891b..06f74460adf62 100644 > > > > > > --- a/drivers/gpu/drm/drm_dumb_buffers.c > > > > > > +++ b/drivers/gpu/drm/drm_dumb_buffers.c > > > > > > @@ -57,7 +57,12 @@ > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 * > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 * Note that dumb objects may not be us= ed for gpu > > > > > > acceleration, > > > > > > as has been > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 * attempted on some ARM embedded platf= orms. Such > > > > > > drivers > > > > > > really > > > > > > must have > > > > > > - * a hardware-specific ioctl to allocate suitable buffer > > > > > > objects. > > > > > > + * a hardware-specific ioctl to allocate suitable buffer > > > > > > objects. > > > > > > They are > > > > > > + * also currently meant for only linear buffers, and using > > > > > > them > > > > > > with any > > > > > > + * modifier other than DRM_FORMAT_MOD_LINEAR is undefined > > > > > > behavior. There > > > > > > + * exist some KMS drivers abusing dumb objects for AFBC > > > > > > framebuffers, but this > > > > > > + * behavior is discouraged, only exists as a hack now and > > > > > > shouldn't be > > > > > > + * replicated. > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0 */ > > > > > > =C2=A0=C2=A0=C2=A0=20 > > > > > > =C2=A0=C2=A0=C2=A0 static int drm_mode_align_dumb(struct > > > > > > drm_mode_create_dumb > > > > > > *args,