> On Feb 28, 2019, at 5:07 AM, Nicolas Dufresne <nicolas@xxxxxxxxxxxx> wrote: > > Hi Ayaka, > >> Le mercredi 27 février 2019 à 23:13 +0800, Ayaka a écrit : >> Last time in FOSDEM, kwiboo and I talk some problems of the request >> API and stateless decoder, I say the a method to describe a buffer >> with many offsets as the buffer meta data would solve the most of >> problems we talked, but I have no idea on how to implement it. And I >> think a buffer meta describing a buffer with many offsets would solve >> this problem as well. > > for single allocation case, the only supported in-between plane padding > is an evenly distributed padding. This padding is communicated to > userspace through S_FMT, by extending the width and height. Userspace > then reads the display width/height through G_SELECTION API. It can solve the partly problem, it is hard to use only width and height to describe a buffer. For hevc and rkvdec decoder in 128bytes mode, it is aligned with 128 bytes plus 128bytes. Sometimes, the padding data may. just less than a component. In that case, only offset would solve this problem. > > For anything else, the MPLANE structure with one of the multi-plane > format can "express" such buffer, though from userspace they are > exposed as two memory pointer or DMABuf FDs (which make importation The video output(VOP) supports two address for luma and chroma and the new generation of rkvdec supports that as well. But for the general situation, we should think we can only set one DMA address to the device. > complicated if the buffer should initially be within a single > allocation). I'll leave to kernel dev the task to explain what is > feasible there (e.g. sub-buffering, etc.) I think it can use the same fd but with a different data_offset in struct v4l2_plane(with a larger number of byteused in the second plane). If I can find a solution to solve this problem, it would be hard to future develop on the stateless media device. Please help on this problem. > > Nicolas >
