Hi,
On 16/01/2025 11:38, Laurent Pinchart wrote:
On Thu, Jan 16, 2025 at 10:43:40AM +0200, Laurent Pinchart wrote:
On Wed, Jan 15, 2025 at 02:34:26PM +0000, Daniel Stone wrote:
On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen wrote:
No disagreement there, we need CREATE_DUMB2.
My point is that we have the current UAPI, and we have userspace using
it, but we don't have clear rules what the ioctl does with specific
parameters, and we don't document how it has to be used.
Perhaps the situation is bad, and all we can really say is that
CREATE_DUMB only works for use with simple RGB formats, and the behavior
for all other formats is platform specific. But I think even that would
be valuable in the UAPI docs.
Yeah, CREATE_DUMB only works for use with simple RGB formats in a
linear layout. Not monochrome or YUV or tiled or displayed rotated or
whatever.
If it happens to accidentally work for other uses, that's fine, but
it's not generically reliable for anything other than simple linear
RGB. It's intended to let you do splash screens, consoles, recovery
password entries, and software-rendered compositors if you really
want. Anything more than that isn't 'dumb'.
We have lots of software out there that rely on CREATE_DUMB supporting
YUV linear formats, and lots of drivers (mostly on Arm I suppose) that
implement YUV support in CREATE_DUMB. I'm fine replacing it with
something better, but I think we need a standard ioctl that can create
linear YUV buffers. I've been told many times that DRM doesn't want to
standardize buffer allocation further than what CREATE_DUMB is made for.
Can we reconsider this rule then ?
Actually... Instead of adding a CREATE_DUMB2, it would be best on trying
to leverage DMA heaps and deprecate allocating from the KMS device.
If we allocate from DMA heaps, I think we then need a DRM ioctl which
will tell you how big buffer(s) you need, based on the size and format.
Tomi
