Hi Nicolas & Dmitry On Fri, 25 Mar 2022 at 12:32, Nicolas Dufresne <nicolas@xxxxxxxxxxxx> wrote: > > Le jeudi 24 mars 2022 à 21:20 +0300, Dmitry Osipenko a écrit : > > The root of the problem is that DRM UAPI is more flexible and allows to > > customize offsets for both S/MPLANEs, while V4L doesn't allow to do it > > at all. I'm exploring all the potential options, so far neither of the > > proposed variants is ideal. > > In GStreamer kmssink, the way DRM is used, is that if you have 2 planes in your > pixel format, but only received 1 DMABuf, we will pass this DMABuf twice (well > GEM handles, but twice), with appropriate offset. > > With this in mind, the idea for V4L2 could be to always resort to MPLANE for > this purpose. The tricky part for userland is that it needs to know the dual > pixel format and map that accordingly. That is a bit difficult and this is > something Helen was trying to address with the v4l2_buffer_ext (that and > allowing space to store DRM Modifiers in the future). > > The second challenge is the overhead. In DRM, as we "prime" the DMABuf into > handles, this gives a kernel object to store any relevant information about the > buffer. So having it duplicate can be done at no cost. In V4L2, the driver would > need to handle that more often. Specially that despite the recommendation > (except for primary buffer decoder, were this is mandatory), we don't force a > strict DMABuf / Buffer IDX mapping. To throw another use case of data offsets into the mix, I'm keeping a watching eye on implementing stereoscopic capture into libcamera where we want to present the same buffer to the ISP twice (once for each eye) with either a vertical or horizontal offset between the two passes. Adding a data_offset of either a half line or half the frame is the easiest way around that one, although it could potentially be accommodated through the selection API setting a compose region instead. Dave
