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 ? -- Regards, Laurent Pinchart
