Hi, I'm looking at the sun4i DRM driver these days (especially for mainlining the VPU tiled format support through the frontend). The way things are done currently, all the possibly-supported plane formats are listed in sun4i_backend_layer_formats and exposed as-is to userspace for every plane. However, some of these formats cannot be used on all planes at the same time and will be rejected when checking the atomic commit. I find this a bit confusing from a userspace perspective. Not all constraints can be provided to userspace (e.g. the number of planes we can effectively scale), but when it comes to formats, we have that possibility. So perhaps it would make sense to only enumerate formats as many times as we can support them. For instance, it could look like: # plane 0: primary, RGB only # plane 1: overlay, RGB + backend YUV formats # plane 2: overlay, RGB + frontend YUV formats # plane 3: overlay, RGB only That's not perfect either, because e.g. requesting a scaled RGB plane will require the frontend and thus make it impossible to use the frontend YUV formats that would still be described. But it feels like it would be closer to representing hardware capabilities than our current situation. I am really not sure about the DRM subsystem policy about this, though. Perhaps it was already decided that it's fine to deal with everything at commit checking time and report more formats than the hardware can really handle. For sun8i and onwards, there is a clear separation between UI and video planes in both the hardware and the code, so this problem doesn't occur (only video planes are reported to support YUV). What do you think? Cheers, Paul -- Developer of free digital technology and hardware support. Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
