On Thu, Jan 16, 2025 at 12:07:49PM +0200, Tomi Valkeinen wrote: > 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. We will at least a kernel API to expose constraints to userspace. Whether that should calculate the buffer size for a given format, or expose information to userspace to enable that calculation, I'm not sure. But regardless of which option we pick, I agree we likely need a new API to enable usage of DMA heaps as allocators. -- Regards, Laurent Pinchart
