[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 02/25] drm/dumb-buffers: Provide helper to set pitch and size
- To: Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx>, maarten.lankhorst@xxxxxxxxxxxxxxx, mripard@xxxxxxxxxx, airlied@xxxxxxxxx, simona@xxxxxxxx
- From: Thomas Zimmermann <tzimmermann@xxxxxxx>
- Date: Thu, 20 Feb 2025 11:05:07 +0100
- Authentication-results: smtp-out2.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=U56jNFDp; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=Y6Z3Xnwq
- Autocrypt: addr=tzimmermann@xxxxxxx; keydata= xsBNBFs50uABCADEHPidWt974CaxBVbrIBwqcq/WURinJ3+2WlIrKWspiP83vfZKaXhFYsdg XH47fDVbPPj+d6tQrw5lPQCyqjwrCPYnq3WlIBnGPJ4/jreTL6V+qfKRDlGLWFjZcsrPJGE0 BeB5BbqP5erN1qylK9i3gPoQjXGhpBpQYwRrEyQyjuvk+Ev0K1Jc5tVDeJAuau3TGNgah4Yc hdHm3bkPjz9EErV85RwvImQ1dptvx6s7xzwXTgGAsaYZsL8WCwDaTuqFa1d1jjlaxg6+tZsB 9GluwvIhSezPgnEmimZDkGnZRRSFiGP8yjqTjjWuf0bSj5rUnTGiyLyRZRNGcXmu6hjlABEB AAHNJ1Rob21hcyBaaW1tZXJtYW5uIDx0emltbWVybWFubkBzdXNlLmRlPsLAjgQTAQgAOAIb AwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftODH AAoJEGgNwR1TC3ojx1wH/0hKGWugiqDgLNXLRD/4TfHBEKmxIrmfu9Z5t7vwUKfwhFL6hqvo lXPJJKQpQ2z8+X2vZm/slsLn7J1yjrOsoJhKABDi+3QWWSGkaGwRJAdPVVyJMfJRNNNIKwVb U6B1BkX2XDKDGffF4TxlOpSQzdtNI/9gleOoUA8+jy8knnDYzjBNOZqLG2FuTdicBXblz0Mf vg41gd9kCwYXDnD91rJU8tzylXv03E75NCaTxTM+FBXPmsAVYQ4GYhhgFt8S2UWMoaaABLDe 7l5FdnLdDEcbmd8uLU2CaG4W2cLrUaI4jz2XbkcPQkqTQ3EB67hYkjiEE6Zy3ggOitiQGcqp j//OwE0EWznS4AEIAMYmP4M/V+T5RY5at/g7rUdNsLhWv1APYrh9RQefODYHrNRHUE9eosYb T6XMryR9hT8XlGOYRwKWwiQBoWSDiTMo/Xi29jUnn4BXfI2px2DTXwc22LKtLAgTRjP+qbU6 3Y0xnQN29UGDbYgyyK51DW3H0If2a3JNsheAAK+Xc9baj0LGIc8T9uiEWHBnCH+RdhgATnWW GKdDegUR5BkDfDg5O/FISymJBHx2Dyoklv5g4BzkgqTqwmaYzsl8UxZKvbaxq0zbehDda8lv hFXodNFMAgTLJlLuDYOGLK2AwbrS3Sp0AEbkpdJBb44qVlGm5bApZouHeJ/+n+7r12+lqdsA EQEAAcLAdgQYAQgAIAIbDBYhBHIX+6yM6c9jRKFo5WgNwR1TC3ojBQJftOH6AAoJEGgNwR1T C3ojVSkIALpAPkIJPQoURPb1VWjh34l0HlglmYHvZszJWTXYwavHR8+k6Baa6H7ufXNQtThR yIxJrQLW6rV5lm7TjhffEhxVCn37+cg0zZ3j7zIsSS0rx/aMwi6VhFJA5hfn3T0TtrijKP4A SAQO9xD1Zk9/61JWk8OysuIh7MXkl0fxbRKWE93XeQBhIJHQfnc+YBLprdnxR446Sh8Wn/2D Ya8cavuWf2zrB6cZurs048xe0UbSW5AOSo4V9M0jzYI4nZqTmPxYyXbm30Kvmz0rYVRaitYJ 4kyYYMhuULvrJDMjZRvaNe52tkKAvMevcGdt38H4KSVXAylqyQOW5zvPc4/sq9c=
- Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx, linux-mediatek@xxxxxxxxxxxxxxxxxxx, freedreno@xxxxxxxxxxxxxxxxxxxxx, linux-arm-msm@xxxxxxxxxxxxxxx, imx@xxxxxxxxxxxxxxx, linux-samsung-soc@xxxxxxxxxxxxxxx, nouveau@xxxxxxxxxxxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxxx, spice-devel@xxxxxxxxxxxxxxxxxxxxx, linux-renesas-soc@xxxxxxxxxxxxxxx, linux-rockchip@xxxxxxxxxxxxxxxxxxx, linux-tegra@xxxxxxxxxxxxxxx, intel-xe@xxxxxxxxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 20 Feb 2025 10:05:18 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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)
|