Hi,
> Cool. I left out SCANOUT_FLUSH in v3 since AFAICT we'll only have one
> blob resource per scanout, and that blob resource will encompass the
> entire window (since we set_scanout when display parameters change).
> And to update the scanout blob resource, we can just call
> RESOURCE_FLUSH.
Hmm, right, using the SET_SCANOUT parameters in case of BLOB resources
should work.
> Though SCANOUT_FLUSH does make sense if you want multiple blob
> resources per scanout surface, so if there's a desire for some
> additional functionality, LMK.
Other way around: one big framebuffer/resource backing multiple
scanouts.
xorg used to handle multihead setups that way, but these days it is
rather uncommon. Typically userspace creates one drm framebuffer
per drm crtc. So, yes, I guess we don't have to worry much.
> Also, TRANSFER_BLOB is also another maintenance vs. future proofing
> tradeoff -- for example, emulated coherent memory[1] (for platforms
> without the host-visible region or external memory extensions or
> shared guest) may benefit from such an API. However, the
> implementation of that doesn't exist and may not for a while (focusing
> on true zero copy for now), and the virglrenderer impl of the
> hypercall will likely just be a stub for now. So if that's
> undesirable, LMK.
Implies the linux kernel can't use blob resources for dumb BOs in
case shared memory isn't available, same goes for dma-buf imports
(inside the guest).
cheers,
Gerd
