Hi
Am 15.01.25 um 14:33 schrieb Tomi Valkeinen:
[...]
Yeah, there are constrains in the scanline and buffer alignments and
orientation. And if we say that bpp==12 means NV12, it will be a
problem for all other cases where bpp==12 makes sense.
I feel I still don't quite understand. Can't we define and document
CREATE_DUMB like this:
If (bpp < 8 || is_power_of_two(bpp))
bpp means bitsperpixel
pitch is args->width * args->bpp / 8, aligned up to
driver-specific-align
else
bpp is a legacy parameter, and we deal with it case by case.
list the cases and what they mean
And describe that when allocating subsampled buffers, the caller must
adjust the width and height accordingly. And that the bpp and width
can also refer to pixel groups.
Or if the currently existing code prevents the above for 16 and 32
bpps, how about defining that any non-RGB or not-simple buffer has to
be allocated with bpp=8, and the userspace has to align the pitch
correctly according to the format and platform's hw restrictions?
What if a hardware requires certain per-format alignments? Or requires
certain alignments for each plane? Or only supports tile modes? Or has
strict limits on the maximum buffer size?
It is not possible to encode all this in a simple 32-bit value. So
user-space code has to be aware of all this and tweak bpp-based
allocation to make it work. Obviously you can use the current UAPI for
your use case. It's just not optimal or future proof.
Best regards
Thomas
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)
