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. regards Philipp
