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

[Thomas Zimmermann <tzimmermann@suse.de>]

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
>

-- 
--
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)