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

[Thomas Zimmermann <tzimmermann@xxxxxxx>]

Hi

Am 21.02.25 um 10:57 schrieb Geert Uytterhoeven:
> Hi Thomas,
>
> On Fri, 21 Feb 2025 at 10:19, Thomas Zimmermann <tzimmermann@xxxxxxx> 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
--
--
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)