Hi,
> > So add a note that this is for future planar format support?
> > Or do we want add planar formats now?
>
> No YUV support for now. I was mostly thinking about compressed
> standard formats (AB24, AR24) with a header + data plane
> (I915_FORMAT_MOD_Y_TILED_CCS etc.). The modifier can be queried from
> virglrenderer in the distant future to avoid modifiers in the guest
> (which is another can of worms). Will write a note about that.
Ok, good.
> > Also: should resource_id an array too? So we have the option to store
> > each plane in a different resource (simliar to drm_framebuffer in the
> > linux kernel)?
>
> It's a cost vs. level of future-proofing tradeoff.
>
> Pros:
> + To mirror the KMS/wayland APIs, a resource_id array +
> VIRTIO_GPU_CMD_SET_SCANOUT_BLOBS makes sense.
> Cons
> - The trend seems to be one buffer. I've only encountered disjoint
> YUV images on deprecated platforms, and reviewing the modifiers in
> <drm_fourcc.h> seem to be one buffer too.
Ok. I guess it makes sense to stick to one buffer then. An API which
isn't used in practice is a maintenance burden we better avoid ...
take care,
Gerd
