Hi Philipp, On Mon, Oct 22, 2018 at 1:28 AM Philipp Zabel <pza@xxxxxxxxxxxxxx> wrote: > > On Wed, Oct 03, 2018 at 05:24:39PM +0900, Tomasz Figa wrote: > [...] > > > Yes, but that would fall in a complete redesign I guess. The buffer > > > allocation scheme is very inflexible. You can't have buffers of two > > > dimensions allocated at the same time for the same queue. Worst, you > > > cannot leave even 1 buffer as your scannout buffer while reallocating > > > new buffers, this is not permitted by the framework (in software). As a > > > side effect, there is no way to optimize the resolution changes, you > > > even have to copy your scannout buffer on the CPU, to free it in order > > > to proceed. Resolution changes are thus painfully slow, by design. > [...] > > Also, I fail to understand the scanout issue. If one exports a vb2 > > buffer to a DMA-buf and import it to the scanout engine, it can keep > > scanning out from it as long as it want, because the DMA-buf will hold > > a reference on the buffer, even if it's removed from the vb2 queue. > > REQBUFS 0 fails if the vb2 buffer is still in use, including from dmabuf > attachments: vb2_buffer_in_use checks the num_users memop. The refcount > returned by num_users shared between the vmarea handler and dmabuf ops, > so any dmabuf attachment counts towards in_use. Ah, right. I've managed to completely forget about it, since we have a downstream patch that we attempted to upstream earlier [1], but didn't have a chance to follow up on the comments and there wasn't much interest in it in general. [1] https://lore.kernel.org/patchwork/patch/607853/ Perhaps it would be worth reviving? Best regards, Tomasz
