| Message ID | 20250218142542.438557-3-tzimmermann@suse.de (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | drm/dumb-buffers: Fix and improve buffer-size calculation | expand |
Hi Thomas, On Tue, 18 Feb 2025 at 15:26, Thomas Zimmermann <tzimmermann@suse.de> wrote: > Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer > scanline pitch and allocation size. Implementations of struct > drm_driver.dumb_create can call the new helper for their size > computations. > > There is currently quite a bit of code duplication among DRM's > memory managers. Each calculates scanline pitch and buffer size > from the given arguments, but the implementations are inconsistent > in how they treat alignment and format support. Later patches will > unify this code on top of drm_mode_size_dumb() as much as possible. > > drm_mode_size_dumb() uses existing 4CC format helpers to interpret > the given color mode. This makes the dumb-buffer interface behave > similar the kernel's video= parameter. Current per-driver implementations > again likely have subtle differences or bugs in how they support color > modes. > > The dumb-buffer UAPI is only specified for known color modes. These > values describe linear, single-plane RGB color formats or legacy index > formats. Other values should not be specified. But some user space > still does. So for unknown color modes, there are a number of known > exceptions for which drm_mode_size_dumb() calculates the pitch from > the bpp value, as before. All other values work the same but print > an error. > > v3: > - document the UAPI semantics > - compute scanline pitch from for unknown color modes (Andy, Tomi) > > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Thanks for your patch! > --- a/drivers/gpu/drm/drm_dumb_buffers.c > +++ b/drivers/gpu/drm/drm_dumb_buffers.c > +/** > + * drm_mode_size_dumb - Calculates the scanline and buffer sizes for dumb buffers > + * @dev: DRM device > + * @args: Parameters for the dumb buffer > + * @pitch_align: Scanline alignment in bytes > + * @size_align: Buffer-size alignment in bytes > + * > + * The helper drm_mode_size_dumb() calculates the size of the buffer > + * allocation and the scanline size for a dumb buffer. Callers have to > + * set the buffers width, height and color mode in the argument @arg. > + * The helper validates the correctness of the input and tests for > + * possible overflows. If successful, it returns the dumb buffer's > + * required scanline pitch and size in &args. > + * > + * The parameter @pitch_align allows the driver to specifies an > + * alignment for the scanline pitch, if the hardware requires any. The > + * calculated pitch will be a multiple of the alignment. The parameter > + * @size_align allows to specify an alignment for buffer sizes. The > + * returned size is always a multiple of PAGE_SIZE. > + * > + * Returns: > + * Zero on success, or a negative error code otherwise. > + */ > +int drm_mode_size_dumb(struct drm_device *dev, > + struct drm_mode_create_dumb *args, > + unsigned long pitch_align, > + unsigned long size_align) > +{ > + u64 pitch = 0; > + u32 fourcc; > + > + /* > + * The scanline pitch depends on the buffer width and the color > + * format. The latter is specified as a color-mode constant for > + * which we first have to find the corresponding color format. > + * > + * Different color formats can have the same color-mode constant. > + * For example XRGB8888 and BGRX8888 both have a color mode of 32. > + * It is possible to use different formats for dumb-buffer allocation > + * and rendering as long as all involved formats share the same > + * color-mode constant. > + */ > + fourcc = drm_driver_color_mode_format(dev, args->bpp); > + if (fourcc != DRM_FORMAT_INVALID) { > + const struct drm_format_info *info = drm_format_info(fourcc); > + > + if (!info) > + return -EINVAL; > + pitch = drm_format_info_min_pitch(info, 0, args->width); > + } else if (args->bpp) { > + /* > + * Some userspace throws in arbitrary values for bpp and > + * relies on the kernel to figure it out. In this case we > + * fall back to the old method of using bpp directly. The > + * over-commitment of memory from the rounding is acceptable > + * for compatibility with legacy userspace. We have a number > + * of deprecated legacy values that are explicitly supported. > + */ > + switch (args->bpp) { > + default: > + drm_warn(dev, "Unknown color mode %d; guessing buffer size.\n", %u > + args->bpp); > + fallthrough; > + case 12: > + case 15: > + case 30: /* see drm_gem_afbc_get_bpp() */ > + case 10: Perhaps keep them sorted numerically? > + case 64: /* used by Mesa */ > + pitch = args->width * DIV_ROUND_UP(args->bpp, SZ_8); > + break; > + } > + } > + > + if (!pitch || pitch > U32_MAX) > + return -EINVAL; > + > + args->pitch = pitch; > + > + return drm_mode_align_dumb(args, pitch_align, size_align); > +} > +EXPORT_SYMBOL(drm_mode_size_dumb); > + > int drm_mode_create_dumb(struct drm_device *dev, > struct drm_mode_create_dumb *args, > struct drm_file *file_priv) > diff --git a/include/drm/drm_dumb_buffers.h b/include/drm/drm_dumb_buffers.h > new file mode 100644 > index 000000000000..6fe36004b19d > --- /dev/null > +++ b/include/drm/drm_dumb_buffers.h > @@ -0,0 +1,14 @@ > +/* SPDX-License-Identifier: MIT */ > + > +#ifndef __DRM_DUMB_BUFFERS_H__ > +#define __DRM_DUMB_BUFFERS_H__ > + > +struct drm_device; > +struct drm_mode_create_dumb; > + > +int drm_mode_size_dumb(struct drm_device *dev, > + struct drm_mode_create_dumb *args, > + unsigned long pitch_align, > + unsigned long size_align); > + > +#endif > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h > index c082810c08a8..eea09103b1a6 100644 > --- a/include/uapi/drm/drm_mode.h > +++ b/include/uapi/drm/drm_mode.h > @@ -1058,7 +1058,7 @@ struct drm_mode_crtc_page_flip_target { > * struct drm_mode_create_dumb - Create a KMS dumb buffer for scanout. > * @height: buffer height in pixels > * @width: buffer width in pixels > - * @bpp: bits per pixel > + * @bpp: color mode > * @flags: must be zero > * @handle: buffer object handle > * @pitch: number of bytes between two consecutive lines > @@ -1066,6 +1066,50 @@ struct drm_mode_crtc_page_flip_target { > * > * User-space fills @height, @width, @bpp and @flags. If the IOCTL succeeds, > * the kernel fills @handle, @pitch and @size. > + * > + * The value of @bpp is a color-mode number describing a specific format > + * or a variant thereof. The value often corresponds to the number of bits > + * per pixel for most modes, although there are exceptions. Each color mode > + * maps to a DRM format plus a number of modes with similar pixel layout. > + * Framebuffer layout is always linear. > + * > + * Support for all modes and formats is optional. Even if dumb-buffer > + * creation with a certain color mode succeeds, it is not guaranteed that > + * the DRM driver supports any of the related formats. Most drivers support > + * a color mode of 32 with a format of DRM_FORMAT_XRGB8888 on their primary > + * plane. > + * > + * +------------+------------------------+------------------------+ > + * | Color mode | Framebuffer format | Compatibles | > + * +============+========================+========================+ > + * | 32 | * DRM_FORMAT_XRGB8888 | * DRM_FORMAT_XBGR8888 | > + * | | | * DRM_FORMAT_RGBX8888 | > + * | | | * DRM_FORMAT_BGRX8888 | > + * +------------+------------------------+------------------------+ > + * | 24 | * DRM_FORMAT_RGB888 | * DRM_FORMAT_BGR888 | > + * +------------+------------------------+------------------------+ > + * | 16 | * DRM_FORMAT_RGB565 | * DRM_FORMAT_BGR565 | > + * +------------+------------------------+------------------------+ > + * | 15 | * DRM_FORMAT_XRGB1555 | * DRM_FORMAT_XBGR1555 | > + * | | | * DRM_FORMAT_RGBX1555 | > + * | | | * DRM_FORMAT_BGRX1555 | > + * +------------+------------------------+------------------------+ > + * | 8 | * DRM_FORMAT_C8 | * DRM_FORMAT_R8 | + DRM_FORMAT_D8? (and 4/2/1 below) And DRM_FORMAT_Y8, if/when Tomi's series introducing that is accepted... > + * +------------+------------------------+------------------------+ > + * | 4 | * DRM_FORMAT_C4 | * DRM_FORMAT_R4 | > + * +------------+------------------------+------------------------+ > + * | 2 | * DRM_FORMAT_C2 | * DRM_FORMAT_R2 | > + * +------------+------------------------+------------------------+ > + * | 1 | * DRM_FORMAT_C1 | * DRM_FORMAT_R1 | > + * +------------+------------------------+------------------------+ > + * > + * 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. > */ > struct drm_mode_create_dumb { > __u32 height; Gr{oetje,eeting}s, Geert
Hi Am 18.02.25 um 20:32 schrieb Geert Uytterhoeven: [...] >> + args->bpp); >> + fallthrough; >> + case 12: >> + case 15: >> + case 30: /* see drm_gem_afbc_get_bpp() */ >> + case 10: > Perhaps keep them sorted numerically? The first block comes from the afbc helper; the second block from Mesa; hence the odd order. I'll reorder and comment each case individually. > >> + case 64: /* used by Mesa */ >> + pitch = args->width * DIV_ROUND_UP(args->bpp, SZ_8); >> + break; >> + } >> + } >> + >> + if (!pitch || pitch > U32_MAX) >> + return -EINVAL; >> + >> + args->pitch = pitch; >> + >> + return drm_mode_align_dumb(args, pitch_align, size_align); >> +} >> +EXPORT_SYMBOL(drm_mode_size_dumb); >> + >> int drm_mode_create_dumb(struct drm_device *dev, >> struct drm_mode_create_dumb *args, >> struct drm_file *file_priv) >> diff --git a/include/drm/drm_dumb_buffers.h b/include/drm/drm_dumb_buffers.h >> new file mode 100644 >> index 000000000000..6fe36004b19d >> --- /dev/null >> +++ b/include/drm/drm_dumb_buffers.h >> @@ -0,0 +1,14 @@ >> +/* SPDX-License-Identifier: MIT */ >> + >> +#ifndef __DRM_DUMB_BUFFERS_H__ >> +#define __DRM_DUMB_BUFFERS_H__ >> + >> +struct drm_device; >> +struct drm_mode_create_dumb; >> + >> +int drm_mode_size_dumb(struct drm_device *dev, >> + struct drm_mode_create_dumb *args, >> + unsigned long pitch_align, >> + unsigned long size_align); >> + >> +#endif >> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h >> index c082810c08a8..eea09103b1a6 100644 >> --- a/include/uapi/drm/drm_mode.h >> +++ b/include/uapi/drm/drm_mode.h >> @@ -1058,7 +1058,7 @@ struct drm_mode_crtc_page_flip_target { >> * struct drm_mode_create_dumb - Create a KMS dumb buffer for scanout. >> * @height: buffer height in pixels >> * @width: buffer width in pixels >> - * @bpp: bits per pixel >> + * @bpp: color mode >> * @flags: must be zero >> * @handle: buffer object handle >> * @pitch: number of bytes between two consecutive lines >> @@ -1066,6 +1066,50 @@ struct drm_mode_crtc_page_flip_target { >> * >> * User-space fills @height, @width, @bpp and @flags. If the IOCTL succeeds, >> * the kernel fills @handle, @pitch and @size. >> + * >> + * The value of @bpp is a color-mode number describing a specific format >> + * or a variant thereof. The value often corresponds to the number of bits >> + * per pixel for most modes, although there are exceptions. Each color mode >> + * maps to a DRM format plus a number of modes with similar pixel layout. >> + * Framebuffer layout is always linear. >> + * >> + * Support for all modes and formats is optional. Even if dumb-buffer >> + * creation with a certain color mode succeeds, it is not guaranteed that >> + * the DRM driver supports any of the related formats. Most drivers support >> + * a color mode of 32 with a format of DRM_FORMAT_XRGB8888 on their primary >> + * plane. >> + * >> + * +------------+------------------------+------------------------+ >> + * | Color mode | Framebuffer format | Compatibles | >> + * +============+========================+========================+ >> + * | 32 | * DRM_FORMAT_XRGB8888 | * DRM_FORMAT_XBGR8888 | >> + * | | | * DRM_FORMAT_RGBX8888 | >> + * | | | * DRM_FORMAT_BGRX8888 | >> + * +------------+------------------------+------------------------+ >> + * | 24 | * DRM_FORMAT_RGB888 | * DRM_FORMAT_BGR888 | >> + * +------------+------------------------+------------------------+ >> + * | 16 | * DRM_FORMAT_RGB565 | * DRM_FORMAT_BGR565 | >> + * +------------+------------------------+------------------------+ >> + * | 15 | * DRM_FORMAT_XRGB1555 | * DRM_FORMAT_XBGR1555 | >> + * | | | * DRM_FORMAT_RGBX1555 | >> + * | | | * DRM_FORMAT_BGRX1555 | >> + * +------------+------------------------+------------------------+ >> + * | 8 | * DRM_FORMAT_C8 | * DRM_FORMAT_R8 | > + DRM_FORMAT_D8? (and 4/2/1 below) Right, missed that. > > And DRM_FORMAT_Y8, if/when Tomi's series introducing that is accepted... Sure, if it is compatible, it can also go into the third column. Best regards Thomas > >> + * +------------+------------------------+------------------------+ >> + * | 4 | * DRM_FORMAT_C4 | * DRM_FORMAT_R4 | >> + * +------------+------------------------+------------------------+ >> + * | 2 | * DRM_FORMAT_C2 | * DRM_FORMAT_R2 | >> + * +------------+------------------------+------------------------+ >> + * | 1 | * DRM_FORMAT_C1 | * DRM_FORMAT_R1 | >> + * +------------+------------------------+------------------------+ >> + * >> + * 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. >> */ >> struct drm_mode_create_dumb { >> __u32 height; > Gr{oetje,eeting}s, > > Geert >
Hi, On 18/02/2025 16:23, Thomas Zimmermann wrote: > Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer > scanline pitch and allocation size. Implementations of struct > drm_driver.dumb_create can call the new helper for their size > computations. > > There is currently quite a bit of code duplication among DRM's > memory managers. Each calculates scanline pitch and buffer size > from the given arguments, but the implementations are inconsistent > in how they treat alignment and format support. Later patches will > unify this code on top of drm_mode_size_dumb() as much as possible. > > drm_mode_size_dumb() uses existing 4CC format helpers to interpret > the given color mode. This makes the dumb-buffer interface behave > similar the kernel's video= parameter. Current per-driver implementations > again likely have subtle differences or bugs in how they support color > modes. > > The dumb-buffer UAPI is only specified for known color modes. These > values describe linear, single-plane RGB color formats or legacy index > formats. Other values should not be specified. But some user space > still does. So for unknown color modes, there are a number of known > exceptions for which drm_mode_size_dumb() calculates the pitch from > the bpp value, as before. All other values work the same but print > an error. > > v3: > - document the UAPI semantics > - compute scanline pitch from for unknown color modes (Andy, Tomi) > > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > --- > drivers/gpu/drm/drm_dumb_buffers.c | 116 +++++++++++++++++++++++++++++ > include/drm/drm_dumb_buffers.h | 14 ++++ > include/uapi/drm/drm_mode.h | 46 +++++++++++- > 3 files changed, 175 insertions(+), 1 deletion(-) > create mode 100644 include/drm/drm_dumb_buffers.h > > diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c > index 9916aaf5b3f2..600ab281712b 100644 > --- a/drivers/gpu/drm/drm_dumb_buffers.c > +++ b/drivers/gpu/drm/drm_dumb_buffers.c > @@ -25,6 +25,8 @@ > > #include <drm/drm_device.h> > #include <drm/drm_drv.h> > +#include <drm/drm_dumb_buffers.h> > +#include <drm/drm_fourcc.h> > #include <drm/drm_gem.h> > #include <drm/drm_mode.h> > > @@ -57,6 +59,120 @@ > * a hardware-specific ioctl to allocate suitable buffer objects. > */ > > +static int drm_mode_align_dumb(struct drm_mode_create_dumb *args, > + unsigned long pitch_align, > + unsigned long size_align) > +{ > + u32 pitch = args->pitch; > + u32 size; > + > + if (!pitch) > + return -EINVAL; > + > + if (pitch_align) > + pitch = roundup(pitch, pitch_align); > + > + /* overflow checks for 32bit size calculations */ > + if (args->height > U32_MAX / pitch) > + return -EINVAL; > + > + if (!size_align) > + size_align = PAGE_SIZE; > + else if (!IS_ALIGNED(size_align, PAGE_SIZE)) > + return -EINVAL; > + > + size = ALIGN(args->height * pitch, size_align); > + if (!size) > + return -EINVAL; > + > + args->pitch = pitch; > + args->size = size; > + > + return 0; > +} > + > +/** > + * drm_mode_size_dumb - Calculates the scanline and buffer sizes for dumb buffers > + * @dev: DRM device > + * @args: Parameters for the dumb buffer > + * @pitch_align: Scanline alignment in bytes > + * @size_align: Buffer-size alignment in bytes > + * > + * The helper drm_mode_size_dumb() calculates the size of the buffer > + * allocation and the scanline size for a dumb buffer. Callers have to > + * set the buffers width, height and color mode in the argument @arg. > + * The helper validates the correctness of the input and tests for > + * possible overflows. If successful, it returns the dumb buffer's > + * required scanline pitch and size in &args. > + * > + * The parameter @pitch_align allows the driver to specifies an > + * alignment for the scanline pitch, if the hardware requires any. The > + * calculated pitch will be a multiple of the alignment. The parameter > + * @size_align allows to specify an alignment for buffer sizes. The > + * returned size is always a multiple of PAGE_SIZE. > + * > + * Returns: > + * Zero on success, or a negative error code otherwise. > + */ > +int drm_mode_size_dumb(struct drm_device *dev, > + struct drm_mode_create_dumb *args, > + unsigned long pitch_align, > + unsigned long size_align) > +{ > + u64 pitch = 0; > + u32 fourcc; > + > + /* > + * The scanline pitch depends on the buffer width and the color > + * format. The latter is specified as a color-mode constant for > + * which we first have to find the corresponding color format. > + * > + * Different color formats can have the same color-mode constant. > + * For example XRGB8888 and BGRX8888 both have a color mode of 32. > + * It is possible to use different formats for dumb-buffer allocation > + * and rendering as long as all involved formats share the same > + * color-mode constant. > + */ > + fourcc = drm_driver_color_mode_format(dev, args->bpp); > + if (fourcc != DRM_FORMAT_INVALID) { > + const struct drm_format_info *info = drm_format_info(fourcc); > + > + if (!info) > + return -EINVAL; > + pitch = drm_format_info_min_pitch(info, 0, args->width); > + } else if (args->bpp) { > + /* > + * Some userspace throws in arbitrary values for bpp and > + * relies on the kernel to figure it out. In this case we > + * fall back to the old method of using bpp directly. The > + * over-commitment of memory from the rounding is acceptable > + * for compatibility with legacy userspace. We have a number > + * of deprecated legacy values that are explicitly supported. > + */ > + switch (args->bpp) { > + default: > + drm_warn(dev, "Unknown color mode %d; guessing buffer size.\n", > + args->bpp); > + fallthrough; > + case 12: > + case 15: > + case 30: /* see drm_gem_afbc_get_bpp() */ > + case 10: > + case 64: /* used by Mesa */ > + pitch = args->width * DIV_ROUND_UP(args->bpp, SZ_8); > + break; > + } > + } > + > + if (!pitch || pitch > U32_MAX) > + return -EINVAL; > + > + args->pitch = pitch; > + > + return drm_mode_align_dumb(args, pitch_align, size_align); > +} > +EXPORT_SYMBOL(drm_mode_size_dumb); > + > int drm_mode_create_dumb(struct drm_device *dev, > struct drm_mode_create_dumb *args, > struct drm_file *file_priv) > diff --git a/include/drm/drm_dumb_buffers.h b/include/drm/drm_dumb_buffers.h > new file mode 100644 > index 000000000000..6fe36004b19d > --- /dev/null > +++ b/include/drm/drm_dumb_buffers.h > @@ -0,0 +1,14 @@ > +/* SPDX-License-Identifier: MIT */ > + > +#ifndef __DRM_DUMB_BUFFERS_H__ > +#define __DRM_DUMB_BUFFERS_H__ > + > +struct drm_device; > +struct drm_mode_create_dumb; > + > +int drm_mode_size_dumb(struct drm_device *dev, > + struct drm_mode_create_dumb *args, > + unsigned long pitch_align, > + unsigned long size_align); > + > +#endif > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h > index c082810c08a8..eea09103b1a6 100644 > --- a/include/uapi/drm/drm_mode.h > +++ b/include/uapi/drm/drm_mode.h > @@ -1058,7 +1058,7 @@ struct drm_mode_crtc_page_flip_target { > * struct drm_mode_create_dumb - Create a KMS dumb buffer for scanout. > * @height: buffer height in pixels > * @width: buffer width in pixels > - * @bpp: bits per pixel > + * @bpp: color mode > * @flags: must be zero > * @handle: buffer object handle > * @pitch: number of bytes between two consecutive lines > @@ -1066,6 +1066,50 @@ struct drm_mode_crtc_page_flip_target { > * > * User-space fills @height, @width, @bpp and @flags. If the IOCTL succeeds, > * the kernel fills @handle, @pitch and @size. > + * > + * The value of @bpp is a color-mode number describing a specific format > + * or a variant thereof. The value often corresponds to the number of bits > + * per pixel for most modes, although there are exceptions. Each color mode > + * maps to a DRM format plus a number of modes with similar pixel layout. > + * Framebuffer layout is always linear. > + * > + * Support for all modes and formats is optional. Even if dumb-buffer > + * creation with a certain color mode succeeds, it is not guaranteed that > + * the DRM driver supports any of the related formats. Most drivers support > + * a color mode of 32 with a format of DRM_FORMAT_XRGB8888 on their primary > + * plane. > + * > + * +------------+------------------------+------------------------+ > + * | Color mode | Framebuffer format | Compatibles | > + * +============+========================+========================+ > + * | 32 | * DRM_FORMAT_XRGB8888 | * DRM_FORMAT_XBGR8888 | > + * | | | * DRM_FORMAT_RGBX8888 | > + * | | | * DRM_FORMAT_BGRX8888 | > + * +------------+------------------------+------------------------+ > + * | 24 | * DRM_FORMAT_RGB888 | * DRM_FORMAT_BGR888 | > + * +------------+------------------------+------------------------+ > + * | 16 | * DRM_FORMAT_RGB565 | * DRM_FORMAT_BGR565 | > + * +------------+------------------------+------------------------+ > + * | 15 | * DRM_FORMAT_XRGB1555 | * DRM_FORMAT_XBGR1555 | > + * | | | * DRM_FORMAT_RGBX1555 | > + * | | | * DRM_FORMAT_BGRX1555 | > + * +------------+------------------------+------------------------+ > + * | 8 | * DRM_FORMAT_C8 | * DRM_FORMAT_R8 | > + * +------------+------------------------+------------------------+ > + * | 4 | * DRM_FORMAT_C4 | * DRM_FORMAT_R4 | > + * +------------+------------------------+------------------------+ > + * | 2 | * DRM_FORMAT_C2 | * DRM_FORMAT_R2 | > + * +------------+------------------------+------------------------+ > + * | 1 | * DRM_FORMAT_C1 | * DRM_FORMAT_R1 | > + * +------------+------------------------+------------------------+ > + * > + * 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? 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? 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. 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
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 >
Hi, On 20/02/2025 12:05, Thomas Zimmermann wrote: > 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? For every dumb_buffer allocation with bpp that is not divisible by 8, the result is different, i.e. instead of DIV_ROUND_UP(width * bpp, 8), we now have width * DIV_ROUND_UP(bpp, 8). This, of course, depends on the driver implementation. Some already do the latter. This change also first calls the drm_driver_color_mode_format(), which could change the behavior even more, but afaics at the moment does not. Although, maybe some platform does width * DIV_ROUND_UP(bpp, 8) even for bpp < 8, and then this series changes it for 1, 2 and 4 bpps (but not for 3, 5, 6, 7, if I'm not mistaken). However, as the bpp is getting rounded up, this probably won't break any user. But it _is_ a change in the behavior of a uapi, and every time we change a uapi that's been out there for a long time, I'm getting slightly uncomfortable. So, as a summary, I have a feeling that nothing will break, but I can't say for sure. And as I'm having trouble seeing the benefit of this change for the user, I get even more uncomfortable. Tomi
Hi Am 20.02.25 um 11:53 schrieb Tomi Valkeinen: > Hi, > > On 20/02/2025 12:05, Thomas Zimmermann wrote: >> 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? > > For every dumb_buffer allocation with bpp that is not divisible by 8, > the result is different, i.e. instead of DIV_ROUND_UP(width * bpp, 8), > we now have width * DIV_ROUND_UP(bpp, 8). This, of course, depends on > the driver implementation. Some already do the latter. The current dumb-buffer code does a stride computation at [1], which is correct for all cases; although over-allocates sometimes. It's the one you describe as "width * DIV_ROUND_UP(bpp, 8)". It's in the ioctl entry point, so it's somewhat authoritative for all driver's implementations. It's also used by several drivers. The other variant, "DIV_ROUND_UP(width * bpp, 8)", is used by gem-dma, gem-shmem and others. It can give incorrect results and possibly OOBs. To give a simple example, let's allocate 15-bit XRGB1555. Bpp is 15. With a width of 1024, that would result in 1920 bytes per scanline. But because XRGB1555 has a filler bit, so the pixel is actually 16 bit and a scanline needs to be 2048 bytes. The new code fixes that. This is not just a hypothetical scenario: we do have drivers that support XRGB1555 and some of them also export a preferred_depth of 15 to userspace. [2] In the nearby comment, you'll see that this value is meant for dumb buffers. Rounding up the depth value in user space is possible for RGB, but not for YUV. Here different pixel planes have a different number of bits. Sometimes pixels are sharing bits. The value of bits-per-pixel becomes meaningless. That's why it's also deprecated in struct drm_format_info. The struct instead uses a more complicated per-plane calculation to compute the number of bits per plane. [3] The user-space code currently doing YUV on dumb buffers simply got lucky. [1] https://elixir.bootlin.com/linux/v6.13.3/source/drivers/gpu/drm/drm_dumb_buffers.c#L77 [2] https://elixir.bootlin.com/linux/v6.13.3/source/include/drm/drm_mode_config.h#L885 [3] https://elixir.bootlin.com/linux/v6.13.3/source/include/drm/drm_fourcc.h#L83 > > This change also first calls the drm_driver_color_mode_format(), which > could change the behavior even more, but afaics at the moment does not. Because currently each driver does its own thing, it can be hard to write user space that reliably allocates on all drivers. That's why it's important that parameters are not just raw numbers, but have well-defined semantics. The raw bpp is meaningless; it's also important to know which formats are associated with each value. Otherwise, you might get a dumb buffer with a bpp of 15, but it will be displayed incorrectly. This patch series finally implements this and clearly documents the assumptions behind the interfaces. The assumptions themselves have always existed. The color modes in drm_driver_color_mode_format() are set in stone and will not change incompatibly. It's already a user interface. I've taken care that the results do not change incompatibly compared to what the dumb-buffer ioctl currently assumes. (C1-C4 are special, see below.) > Although, maybe some platform does width * DIV_ROUND_UP(bpp, 8) even > for bpp < 8, and then this series changes it for 1, 2 and 4 bpps (but > not for 3, 5, 6, 7, if I'm not mistaken). True. 1, 2 and 4 would currently over-allocate significantly on some drivers and the series will reduce this to actual requirements. Yet our most common memory managers, gem-dma and gem-shmem, compute the sizes correctly. But there are currently no drivers that support C4, C2 or C1 formats; hence there's likely no user space either. I know that Geert is interested in making a driver that uses these formats on very low-end hardware (something Atari or Amiga IIRC). Over-allocating on such hardware is likely not an option. The other values (3, 5, 6, 7) have no meaning I know of. 6 could be XRGB2222, but I not aware of anything using that. We don't even have a format constant for this. > > However, as the bpp is getting rounded up, this probably won't break > any user. But it _is_ a change in the behavior of a uapi, and every > time we change a uapi that's been out there for a long time, I'm > getting slightly uncomfortable. As I tried to explain, we currently have both versions in drivers: rounding up bpp and rounding up (bpp*width). User-space code already has to deal with both cases. Best regards Thomas > > So, as a summary, I have a feeling that nothing will break, but I > can't say for sure. And as I'm having trouble seeing the benefit of > this change for the user, I get even more uncomfortable. > > Tomi >
Hi Thomas, On Fri, 21 Feb 2025 at 10:19, Thomas Zimmermann <tzimmermann@suse.de> wrote: > Am 20.02.25 um 11:53 schrieb Tomi Valkeinen: > > This change also first calls the drm_driver_color_mode_format(), which > > could change the behavior even more, but afaics at the moment does not. > > Because currently each driver does its own thing, it can be hard to > write user space that reliably allocates on all drivers. That's why it's > important that parameters are not just raw numbers, but have > well-defined semantics. The raw bpp is meaningless; it's also important > to know which formats are associated with each value. Otherwise, you > might get a dumb buffer with a bpp of 15, but it will be displayed > incorrectly. This patch series finally implements this and clearly > documents the assumptions behind the interfaces. The assumptions > themselves have always existed. > > The color modes in drm_driver_color_mode_format() are set in stone and > will not change incompatibly. It's already a user interface. I've taken > care that the results do not change incompatibly compared to what the > dumb-buffer ioctl currently assumes. (C1-C4 are special, see below.) > > > Although, maybe some platform does width * DIV_ROUND_UP(bpp, 8) even > > for bpp < 8, and then this series changes it for 1, 2 and 4 bpps (but > > not for 3, 5, 6, 7, if I'm not mistaken). > > True. 1, 2 and 4 would currently over-allocate significantly on some > drivers and the series will reduce this to actual requirements. Yet our > most common memory managers, gem-dma and gem-shmem, compute the sizes > correctly. > > But there are currently no drivers that support C4, C2 or C1 formats; > hence there's likely no user space either. I know that Geert is > interested in making a driver that uses these formats on very low-end > hardware (something Atari or Amiga IIRC). Over-allocating on such > hardware is likely not an option. Note that the gud and ssd130x drivers do support R1, and I believe work is underway to add grayscale formats to ssd130x. > The other values (3, 5, 6, 7) have no meaning I know of. 6 could be > XRGB2222, but I not aware of anything using that. We don't even have a > format constant for this. Yeah, e.g. Amiga supports 3, 5, 6, and 7 bpp, but that is using bitplanes. There is already some sort of consensus to not expose bitplanes to userspace in DRM, so limiting to 1, 2, 4, and 8 bpp (which can be converted from C[1248]) is fine. Gr{oetje,eeting}s, Geert
Hi Am 21.02.25 um 10:57 schrieb Geert Uytterhoeven: > Hi Thomas, > > On Fri, 21 Feb 2025 at 10:19, Thomas Zimmermann <tzimmermann@suse.de> wrote: >> Am 20.02.25 um 11:53 schrieb Tomi Valkeinen: >>> This change also first calls the drm_driver_color_mode_format(), which >>> could change the behavior even more, but afaics at the moment does not. >> Because currently each driver does its own thing, it can be hard to >> write user space that reliably allocates on all drivers. That's why it's >> important that parameters are not just raw numbers, but have >> well-defined semantics. The raw bpp is meaningless; it's also important >> to know which formats are associated with each value. Otherwise, you >> might get a dumb buffer with a bpp of 15, but it will be displayed >> incorrectly. This patch series finally implements this and clearly >> documents the assumptions behind the interfaces. The assumptions >> themselves have always existed. >> >> The color modes in drm_driver_color_mode_format() are set in stone and >> will not change incompatibly. It's already a user interface. I've taken >> care that the results do not change incompatibly compared to what the >> dumb-buffer ioctl currently assumes. (C1-C4 are special, see below.) >> >>> Although, maybe some platform does width * DIV_ROUND_UP(bpp, 8) even >>> for bpp < 8, and then this series changes it for 1, 2 and 4 bpps (but >>> not for 3, 5, 6, 7, if I'm not mistaken). >> True. 1, 2 and 4 would currently over-allocate significantly on some >> drivers and the series will reduce this to actual requirements. Yet our >> most common memory managers, gem-dma and gem-shmem, compute the sizes >> correctly. >> >> But there are currently no drivers that support C4, C2 or C1 formats; >> hence there's likely no user space either. I know that Geert is >> interested in making a driver that uses these formats on very low-end >> hardware (something Atari or Amiga IIRC). Over-allocating on such >> hardware is likely not an option. > Note that the gud and ssd130x drivers do support R1, and I believe > work is underway to add grayscale formats to ssd130x. Nice find. Both use gem-shmem, which allocates without much overhead. So any possible userspace should already be prepared for this scenario. > >> The other values (3, 5, 6, 7) have no meaning I know of. 6 could be >> XRGB2222, but I not aware of anything using that. We don't even have a >> format constant for this. > Yeah, e.g. Amiga supports 3, 5, 6, and 7 bpp, but that is using > bitplanes. There is already some sort of consensus to not expose > bitplanes to userspace in DRM, so limiting to 1, 2, 4, and 8 bpp > (which can be converted from C[1248]) is fine. There's been discussion about a new dumb-buffer ioctl that receives a format constant and returns individual buffers for each plane. This would allow for these use cases. Best regards Thomas > > Gr{oetje,eeting}s, > > Geert >
diff --git a/drivers/gpu/drm/drm_dumb_buffers.c b/drivers/gpu/drm/drm_dumb_buffers.c index 9916aaf5b3f2..600ab281712b 100644 --- a/drivers/gpu/drm/drm_dumb_buffers.c +++ b/drivers/gpu/drm/drm_dumb_buffers.c @@ -25,6 +25,8 @@ #include <drm/drm_device.h> #include <drm/drm_drv.h> +#include <drm/drm_dumb_buffers.h> +#include <drm/drm_fourcc.h> #include <drm/drm_gem.h> #include <drm/drm_mode.h> @@ -57,6 +59,120 @@ * a hardware-specific ioctl to allocate suitable buffer objects. */ +static int drm_mode_align_dumb(struct drm_mode_create_dumb *args, + unsigned long pitch_align, + unsigned long size_align) +{ + u32 pitch = args->pitch; + u32 size; + + if (!pitch) + return -EINVAL; + + if (pitch_align) + pitch = roundup(pitch, pitch_align); + + /* overflow checks for 32bit size calculations */ + if (args->height > U32_MAX / pitch) + return -EINVAL; + + if (!size_align) + size_align = PAGE_SIZE; + else if (!IS_ALIGNED(size_align, PAGE_SIZE)) + return -EINVAL; + + size = ALIGN(args->height * pitch, size_align); + if (!size) + return -EINVAL; + + args->pitch = pitch; + args->size = size; + + return 0; +} + +/** + * drm_mode_size_dumb - Calculates the scanline and buffer sizes for dumb buffers + * @dev: DRM device + * @args: Parameters for the dumb buffer + * @pitch_align: Scanline alignment in bytes + * @size_align: Buffer-size alignment in bytes + * + * The helper drm_mode_size_dumb() calculates the size of the buffer + * allocation and the scanline size for a dumb buffer. Callers have to + * set the buffers width, height and color mode in the argument @arg. + * The helper validates the correctness of the input and tests for + * possible overflows. If successful, it returns the dumb buffer's + * required scanline pitch and size in &args. + * + * The parameter @pitch_align allows the driver to specifies an + * alignment for the scanline pitch, if the hardware requires any. The + * calculated pitch will be a multiple of the alignment. The parameter + * @size_align allows to specify an alignment for buffer sizes. The + * returned size is always a multiple of PAGE_SIZE. + * + * Returns: + * Zero on success, or a negative error code otherwise. + */ +int drm_mode_size_dumb(struct drm_device *dev, + struct drm_mode_create_dumb *args, + unsigned long pitch_align, + unsigned long size_align) +{ + u64 pitch = 0; + u32 fourcc; + + /* + * The scanline pitch depends on the buffer width and the color + * format. The latter is specified as a color-mode constant for + * which we first have to find the corresponding color format. + * + * Different color formats can have the same color-mode constant. + * For example XRGB8888 and BGRX8888 both have a color mode of 32. + * It is possible to use different formats for dumb-buffer allocation + * and rendering as long as all involved formats share the same + * color-mode constant. + */ + fourcc = drm_driver_color_mode_format(dev, args->bpp); + if (fourcc != DRM_FORMAT_INVALID) { + const struct drm_format_info *info = drm_format_info(fourcc); + + if (!info) + return -EINVAL; + pitch = drm_format_info_min_pitch(info, 0, args->width); + } else if (args->bpp) { + /* + * Some userspace throws in arbitrary values for bpp and + * relies on the kernel to figure it out. In this case we + * fall back to the old method of using bpp directly. The + * over-commitment of memory from the rounding is acceptable + * for compatibility with legacy userspace. We have a number + * of deprecated legacy values that are explicitly supported. + */ + switch (args->bpp) { + default: + drm_warn(dev, "Unknown color mode %d; guessing buffer size.\n", + args->bpp); + fallthrough; + case 12: + case 15: + case 30: /* see drm_gem_afbc_get_bpp() */ + case 10: + case 64: /* used by Mesa */ + pitch = args->width * DIV_ROUND_UP(args->bpp, SZ_8); + break; + } + } + + if (!pitch || pitch > U32_MAX) + return -EINVAL; + + args->pitch = pitch; + + return drm_mode_align_dumb(args, pitch_align, size_align); +} +EXPORT_SYMBOL(drm_mode_size_dumb); + int drm_mode_create_dumb(struct drm_device *dev, struct drm_mode_create_dumb *args, struct drm_file *file_priv) diff --git a/include/drm/drm_dumb_buffers.h b/include/drm/drm_dumb_buffers.h new file mode 100644 index 000000000000..6fe36004b19d --- /dev/null +++ b/include/drm/drm_dumb_buffers.h @@ -0,0 +1,14 @@ +/* SPDX-License-Identifier: MIT */ + +#ifndef __DRM_DUMB_BUFFERS_H__ +#define __DRM_DUMB_BUFFERS_H__ + +struct drm_device; +struct drm_mode_create_dumb; + +int drm_mode_size_dumb(struct drm_device *dev, + struct drm_mode_create_dumb *args, + unsigned long pitch_align, + unsigned long size_align); + +#endif diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index c082810c08a8..eea09103b1a6 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -1058,7 +1058,7 @@ struct drm_mode_crtc_page_flip_target { * struct drm_mode_create_dumb - Create a KMS dumb buffer for scanout. * @height: buffer height in pixels * @width: buffer width in pixels - * @bpp: bits per pixel + * @bpp: color mode * @flags: must be zero * @handle: buffer object handle * @pitch: number of bytes between two consecutive lines @@ -1066,6 +1066,50 @@ struct drm_mode_crtc_page_flip_target { * * User-space fills @height, @width, @bpp and @flags. If the IOCTL succeeds, * the kernel fills @handle, @pitch and @size. + * + * The value of @bpp is a color-mode number describing a specific format + * or a variant thereof. The value often corresponds to the number of bits + * per pixel for most modes, although there are exceptions. Each color mode + * maps to a DRM format plus a number of modes with similar pixel layout. + * Framebuffer layout is always linear. + * + * Support for all modes and formats is optional. Even if dumb-buffer + * creation with a certain color mode succeeds, it is not guaranteed that + * the DRM driver supports any of the related formats. Most drivers support + * a color mode of 32 with a format of DRM_FORMAT_XRGB8888 on their primary + * plane. + * + * +------------+------------------------+------------------------+ + * | Color mode | Framebuffer format | Compatibles | + * +============+========================+========================+ + * | 32 | * DRM_FORMAT_XRGB8888 | * DRM_FORMAT_XBGR8888 | + * | | | * DRM_FORMAT_RGBX8888 | + * | | | * DRM_FORMAT_BGRX8888 | + * +------------+------------------------+------------------------+ + * | 24 | * DRM_FORMAT_RGB888 | * DRM_FORMAT_BGR888 | + * +------------+------------------------+------------------------+ + * | 16 | * DRM_FORMAT_RGB565 | * DRM_FORMAT_BGR565 | + * +------------+------------------------+------------------------+ + * | 15 | * DRM_FORMAT_XRGB1555 | * DRM_FORMAT_XBGR1555 | + * | | | * DRM_FORMAT_RGBX1555 | + * | | | * DRM_FORMAT_BGRX1555 | + * +------------+------------------------+------------------------+ + * | 8 | * DRM_FORMAT_C8 | * DRM_FORMAT_R8 | + * +------------+------------------------+------------------------+ + * | 4 | * DRM_FORMAT_C4 | * DRM_FORMAT_R4 | + * +------------+------------------------+------------------------+ + * | 2 | * DRM_FORMAT_C2 | * DRM_FORMAT_R2 | + * +------------+------------------------+------------------------+ + * | 1 | * DRM_FORMAT_C1 | * DRM_FORMAT_R1 | + * +------------+------------------------+------------------------+ + * + * 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. */ struct drm_mode_create_dumb { __u32 height;
Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer scanline pitch and allocation size. Implementations of struct drm_driver.dumb_create can call the new helper for their size computations. There is currently quite a bit of code duplication among DRM's memory managers. Each calculates scanline pitch and buffer size from the given arguments, but the implementations are inconsistent in how they treat alignment and format support. Later patches will unify this code on top of drm_mode_size_dumb() as much as possible. drm_mode_size_dumb() uses existing 4CC format helpers to interpret the given color mode. This makes the dumb-buffer interface behave similar the kernel's video= parameter. Current per-driver implementations again likely have subtle differences or bugs in how they support color modes. The dumb-buffer UAPI is only specified for known color modes. These values describe linear, single-plane RGB color formats or legacy index formats. Other values should not be specified. But some user space still does. So for unknown color modes, there are a number of known exceptions for which drm_mode_size_dumb() calculates the pitch from the bpp value, as before. All other values work the same but print an error. v3: - document the UAPI semantics - compute scanline pitch from for unknown color modes (Andy, Tomi) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> --- drivers/gpu/drm/drm_dumb_buffers.c | 116 +++++++++++++++++++++++++++++ include/drm/drm_dumb_buffers.h | 14 ++++ include/uapi/drm/drm_mode.h | 46 +++++++++++- 3 files changed, 175 insertions(+), 1 deletion(-) create mode 100644 include/drm/drm_dumb_buffers.h