On Thu, 16 Jan 2025 at 10:35, Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote: > On Thu, Jan 16, 2025 at 11:17:50AM +0100, Geert Uytterhoeven wrote: > > On Thu, Jan 16, 2025 at 11:03 AM Tomi Valkeinen > > <tomi.valkeinen@xxxxxxxxxxxxxxxx> wrote: > > > On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb > > > buffers are the only buffers you can get from the DRM driver. The dumb > > > buffers have been used to allocate linear and multiplanar YUV buffers > > > for a very long time on those platforms. > > > > > > I tried to look around, but I did not find any mentions that CREATE_DUMB > > > should only be used for RGB buffers. Is anyone outside the core > > > developers even aware of it? > > > > > > If we don't use dumb buffers there, where do we get the buffers? Maybe > > > from a v4l2 device or from a gpu device, but often you don't have those. > > > DMA_HEAP is there, of course. > > > > Why can't there be a variant that takes a proper fourcc format instead of > > an imprecise bpp value? > > Backwards compatibility. We can add an IOCTL for YUV / etc. But > userspace must be able to continue allocating YUV buffers through > CREATE_DUMB. Right. If allocating YUYV dumb buffers works on AM68 today, then we need to keep that working. But it doesn't mean we should go out of our way to make CREATE_DUMB work for every YUV format on every device. Currently, drivers are free to implement their own ioctls for anything specific they have. But like Laurent said, standardising on heaps and how to communicate requirements to userspace wrt heap selection / size / alignment / etc is imo a better path forward for something generic. Cheers, Daniel
