Re: [PATCH v3 02/25] drm/dumb-buffers: Provide helper to set pitch and size

From: Thomas Zimmermann <tzimmermann@suse.de>
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	airlied@gmail.com, simona@ffwll.ch
Cc: dri-devel@lists.freedesktop.org,
	linux-mediatek@lists.infradead.org,
	freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
	nouveau@lists.freedesktop.org, virtualization@lists.linux.dev,
	spice-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org,
	intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH v3 02/25] drm/dumb-buffers: Provide helper to set pitch and size
Date: Thu, 20 Feb 2025 11:05:07 +0100	[thread overview]
Message-ID: <355ed315-61fa-4a9d-b72b-8d5bc7b5a16c@suse.de> (raw)
In-Reply-To: <dcd59a75-7945-4a2e-99f9-3abbb3e9de14@ideasonboard.com>

Hi

Am 20.02.25 um 10:18 schrieb Tomi Valkeinen:
[...]
>> + * Color modes of 10, 12, 15, 30 and 64 are only supported for use by
>> + * legacy user space. Please don't use them in new code. Other modes
>> + * are not support.
>> + *
>> + * Do not attempt to allocate anything but linear framebuffer memory
>> + * with single-plane RGB data. Allocation of other framebuffer
>> + * layouts requires dedicated ioctls in the respective DRM driver.
>
> According to this, every driver that supports, say, NV12, should 
> implement their own custom ioctl to do the exact same thing? And, of 
> course, every userspace app that uses, say, NV12, should then add code 
> for all these platforms to call the custom ioctls?

Yes, that's exactly the current status.

There has been discussion about a new dumb-create ioctl that takes a DRM 
format as parameter. I'm all for it, but it's out of the scope for this 
series.

>
> As libdrm's modetest currently supports YUV formats with dumb buffers, 
> should we remove that code, as it's not correct and I'm sure people 
> use libdrm code as a reference?

Of course not.

>
> Well, I'm not serious above, but I think all my points from the 
> earlier version are still valid. I don't like this. It changes the 
> parameters of the ioctl (bpp used to be bits-per-pixel, not it's 
> "color mode"), and the behavior of the ioctl, behavior that we've had 
> for a very long time, and we have no idea how many users there are 
> that will break (could be none, of course). And the documentation 
> changes make the current behavior and uses wrong or legacy.

Before I go into details about this statement, what use case exactly are 
you referring to when you say that behavior changes?

Best regards
Thomas

>
> Clearly we need something new and better for the buffer allocation, 
> but for the time being, I'd be more comfortable just keep the current 
> behavior, at least for all the drivers I use or maintain: omapdrm, 
> tidss, renesas, xlnx, tilcdc.
>
>  Tomi
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip