[{"id":33763,"web_url":"https://patchwork.libcamera.org/comment/33763/","msgid":"<1de7f2b25abbc56d9792a74e0995d71937a860b6.camel@ndufresne.ca>","date":"2025-03-28T20:51:12","subject":"Re: [PATCH 2/3] libcamera: v4l2_videodevice: Report offset in\n\tdequeueBuffer","submitter":{"id":30,"url":"https://patchwork.libcamera.org/api/people/30/","name":"Nicolas Dufresne","email":"nicolas@ndufresne.ca"},"content":"Le mercredi 26 mars 2025 à 16:51 +0900, Paul Elder a écrit :\n> Fill in the offset field of the frame metadata so that it the\n> application can read it.\n> \n> Signed-off-by: Paul Elder \n> ---\n>  src/libcamera/v4l2_videodevice.cpp | 5 ++++-\n>  1 file changed, 4 insertions(+), 1 deletion(-)\n> \n> diff --git a/src/libcamera/v4l2_videodevice.cpp\n> b/src/libcamera/v4l2_videodevice.cpp\n> index f5b3fa09d9a0..5d163f7fd853 100644\n> --- a/src/libcamera/v4l2_videodevice.cpp\n> +++ b/src/libcamera/v4l2_videodevice.cpp\n> @@ -1957,10 +1957,13 @@ FrameBuffer *V4L2VideoDevice::dequeueBuffer()\n>  \t\t * The number of planes in the frame buffer and in\n> the\n>  \t\t * V4L2 buffer is guaranteed to be equal at this\n> point.\n>  \t\t */\n> -\t\tfor (unsigned int i = 0; i < numV4l2Planes; ++i)\n> +\t\tfor (unsigned int i = 0; i < numV4l2Planes; ++i) {\n>  \t\t\tmetadata.planes()[i].bytesused =\n> planes[i].bytesused;\n> +\t\t\tmetadata.planes()[i].offset =\n> planes[i].data_offset;\n\nIn V4L2, data_offset is included in the total bytesused. Once you hit a\nnon-zero offset, you will endup with byteused possibly bigger then\nFrameBuffer.length, which to my reading contradicts the doc.\n\nhttps://www.linuxtv.org/downloads/v4l-dvb-apis/userspace-api/v4l/buffer.html?highlight=data_offset#struct-v4l2-plane\n\n> +\t\t}\n>  \t} else {\n>  \t\tmetadata.planes()[0].bytesused = buf.bytesused;\n> +\t\tmetadata.planes()[0].offset = buf.m.offset;\n\nShould be:\n\n+\t\tmetadata.planes()[0].offset = 0;\n\nThere is no support for data_offset in the original v4l2_buffer API.\nThis offset match planes[i].mem_offset and is only useful for CPU\naccess using mmap() and the video node FD.\n\nI think some introspection is needed, since this offset was expected to\nbe in the framebuffer, which apparently needs to be constant. Once\nthese issue resovled, do you mind fixing GStreamer code to use the\nright one, it reads like this:\n\n\t\tGstMemory *mem = gst_fd_allocator_alloc(allocator, plane.fd.get(),\n\t\t\t\t\t\t\tplane.offset + plane.length,\n\t\t\t\t\t\t\tGST_FD_MEMORY_FLAG_DONT_CLOSE);\n\t\tgst_memory_resize(mem, plane.offset, plane.length);\n\nPlane.offset is never set (always zero atm), but if its constant, its\nthe wrong one, this code should use the metadata once (the variable\none). You will also notice the semantic difference, we assume length\ndoes not include the offset, this might need adjustment.\n\nNicolas\n\n>  \t}\n>  \n>  \treturn buffer;","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 7765DC3213\n\tfor ;\n\tFri, 28 Mar 2025 20:51:17 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id CC29F6897A;\n\tFri, 28 Mar 2025 21:51:16 +0100 (CET)","from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com\n\t[IPv6:2607:f8b0:4864:20::f2d])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 20FC4614E8\n\tfor ;\n\tFri, 28 Mar 2025 21:51:15 +0100 (CET)","by mail-qv1-xf2d.google.com with SMTP id\n\t6a1803df08f44-6df83fd01cbso12770366d6.2\n\tfor ;\n\tFri, 28 Mar 2025 13:51:15 -0700 (PDT)","from ?IPv6:2606:6d00:11:e976::5ac? ([2606:6d00:11:e976::5ac])\n\tby smtp.gmail.com with ESMTPSA id\n\t6a1803df08f44-6eec9779bdfsm15217146d6.92.2025.03.28.13.51.12\n\t(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n\tFri, 28 Mar 2025 13:51:13 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key;\n\tunprotected) header.d=ndufresne-ca.20230601.gappssmtp.com\n\theader.i=@ndufresne-ca.20230601.gappssmtp.com\n\theader.b=\"DXEZrZa8\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ndufresne-ca.20230601.gappssmtp.com; s=20230601; t=1743195074;\n\tx=1743799874; darn=lists.libcamera.org; \n\th=mime-version:user-agent:content-transfer-encoding:references\n\t:in-reply-to:date:to:from:subject:message-id:from:to:cc:subject:date\n\t:message-id:reply-to;\n\tbh=LcV6YAlClCGJ2oGP9mHTviJ89zwbZsLLyX3OfZu5xxQ=;\n\tb=DXEZrZa85DmHudIDPNp8kSRDVX7RbLF7+bED17wpTUl/+t3Ry9zhKPnZ3L6kbQ53tn\n\tHI2hxilbzRwriJPdgQ3PFBLBYjVAAUwMgU6e/AvP4no18jHpN5rqMVw5f1n4IW1/DihI\n\t5LYPYAW1XKPc6PG9DtUZili2fEXGPbyPf825vflBi1EpOCfPy+8qtbd9XsggMT8P+oDu\n\tN6Oy70GfG/BV2BSOL2rmZ9ZcYu7G3WZt/aIy94T1LgBL/I8aK6uKFMfBrpQ9L5MzqKRU\n\tszBSYUUrDhppzcGjmZmxmLIc5xNRrKyiVYwrWA8KHnPlENLwq84sYHGDE9N/PQdE4zN0\n\tcKSQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20230601; t=1743195074; x=1743799874;\n\th=mime-version:user-agent:content-transfer-encoding:references\n\t:in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from\n\t:to:cc:subject:date:message-id:reply-to;\n\tbh=LcV6YAlClCGJ2oGP9mHTviJ89zwbZsLLyX3OfZu5xxQ=;\n\tb=NHmdqdLgPvB5gDkWLzJsCueO4soljYAIUwAjDZ/dO/H53Ux3wIhvN96F6cTmQ8Wv8x\n\t1GLn2ceUoakaO15Y8ndrnLL8+PbTZUY/33MrmEFyv13wxgOvKro8ON8JQ+TLJaeJ2IZj\n\tdeAvrYb2y857zDGyFtpvKZ/q/X3Quj5G1Xv+m1TEpd525MX/wBJz5vdns0qXgDyseiOh\n\tVP4IeZFlmP/o1CUiE0PB7QYgQczAT42Dpoc2F9zgY2tFNG47I0c61b66PrEmhLdl80Mf\n\tucD4jypJ4uWLG9nXBpp9Q2pG2JQMMx1wFR+A2XA6tkxaZ67sZYkVePpPBl0ZkPCnSizM\n\tIQNw==","X-Forwarded-Encrypted":"i=1;\n\tAJvYcCWSWhgTd4a4gS52kQ7X1M3otA/a2kGWFgGND9pX83N9pKlJsAA7Lk//B/s/RKwmHMihoKLeZKWBwHgUaGu5z98=@lists.libcamera.org","X-Gm-Message-State":"AOJu0Yw6P4F/wkdNMOnwNnB9SUcDtdM/TxEsstT4oBfb4hqRnwW2BCD6\n\tzxpwFhWH7FsiUMEX37J3rjb+wOOAFrus5b9wOeGzK3hsDxfmRjCtHcTmQJDFh2E4oHui4dn1aRA\n\t2","X-Gm-Gg":"ASbGncvq7m70QfSiCcu7DeHN/m8AivBBLMjR3gJRou4c2OvQA+8M6/q35BgmZgQ5jQU\n\tMOJ6fGCUZFsuQ3aGAPj4kluAWsXqmd/0cMgy94qXSKYd+b97fgoieMaIWBF5Al3FdhUzZtyf5bM\n\tloRjdeli9HiTGN3TDpLmOwmcARUpDf3UkvQtzcdR+Mxt2vUZHt6eZt8t39WLAvY1sYRtGqrCbpb\n\tywaQkl2ig0UaikRrf1p+j//OyojWLuv4/53V0QrzusAoSMayEG/B9wD3qbE76SnKVlKcnXJWdGD\n\tiDtSBGH+OJvCWleYMjte7h8r7yUyHKhKIcBDCdRiIlzMmCEwHQ==","X-Google-Smtp-Source":"AGHT+IGfMOMa1f318zhNzV68hQdEkfFfoa3/T7mwe8VTzs9uKuYHpXYuT+4wu4sBG/VcLBmwoj+XJQ==","X-Received":"by 2002:a05:6214:20c3:b0:6e8:955b:141e with SMTP id\n\t6a1803df08f44-6eed6023f5bmr8442556d6.21.1743195073875; \n\tFri, 28 Mar 2025 13:51:13 -0700 (PDT)","Message-ID":"<1de7f2b25abbc56d9792a74e0995d71937a860b6.camel@ndufresne.ca>","Subject":"Re: [PATCH 2/3] libcamera: v4l2_videodevice: Report offset in\n\tdequeueBuffer","From":"Nicolas Dufresne ","To":"Paul Elder , \n\tlibcamera-devel@lists.libcamera.org","Date":"Fri, 28 Mar 2025 16:51:12 -0400","In-Reply-To":"<20250326075129.1705736-3-paul.elder@ideasonboard.com>","References":"<20250326075129.1705736-1-paul.elder@ideasonboard.com>\n\t<20250326075129.1705736-3-paul.elder@ideasonboard.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","User-Agent":"Evolution 3.54.3 (3.54.3-1.fc41) ","MIME-Version":"1.0","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":33876,"web_url":"https://patchwork.libcamera.org/comment/33876/","msgid":"<20250402000942.GA4845@pendragon.ideasonboard.com>","date":"2025-04-02T00:09:42","subject":"Re: [PATCH 2/3] libcamera: v4l2_videodevice: Report offset in\n\tdequeueBuffer","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"On Fri, Mar 28, 2025 at 04:51:12PM -0400, Nicolas Dufresne wrote:\n> Le mercredi 26 mars 2025 à 16:51 +0900, Paul Elder a écrit :\n> > Fill in the offset field of the frame metadata so that it the\n> > application can read it.\n> > \n> > Signed-off-by: Paul Elder \n> > ---\n> >  src/libcamera/v4l2_videodevice.cpp | 5 ++++-\n> >  1 file changed, 4 insertions(+), 1 deletion(-)\n> > \n> > diff --git a/src/libcamera/v4l2_videodevice.cpp\n> > b/src/libcamera/v4l2_videodevice.cpp\n> > index f5b3fa09d9a0..5d163f7fd853 100644\n> > --- a/src/libcamera/v4l2_videodevice.cpp\n> > +++ b/src/libcamera/v4l2_videodevice.cpp\n> > @@ -1957,10 +1957,13 @@ FrameBuffer *V4L2VideoDevice::dequeueBuffer()\n> >  \t\t * The number of planes in the frame buffer and in the\n> >  \t\t * V4L2 buffer is guaranteed to be equal at this point.\n> >  \t\t */\n> > -\t\tfor (unsigned int i = 0; i < numV4l2Planes; ++i)\n> > +\t\tfor (unsigned int i = 0; i < numV4l2Planes; ++i) {\n> >  \t\t\tmetadata.planes()[i].bytesused = planes[i].bytesused;\n> > +\t\t\tmetadata.planes()[i].offset = planes[i].data_offset;\n> \n> In V4L2, data_offset is included in the total bytesused. Once you hit a\n> non-zero offset, you will endup with byteused possibly bigger then\n> FrameBuffer.length, which to my reading contradicts the doc.\n> \n> https://www.linuxtv.org/downloads/v4l-dvb-apis/userspace-api/v4l/buffer.html?highlight=data_offset#struct-v4l2-plane\n> \n> > +\t\t}\n> >  \t} else {\n> >  \t\tmetadata.planes()[0].bytesused = buf.bytesused;\n> > +\t\tmetadata.planes()[0].offset = buf.m.offset;\n> \n> Should be:\n> \n> +\t\tmetadata.planes()[0].offset = 0;\n> \n> There is no support for data_offset in the original v4l2_buffer API.\n> This offset match planes[i].mem_offset and is only useful for CPU\n> access using mmap() and the video node FD.\n> \n> I think some introspection is needed, since this offset was expected to\n> be in the framebuffer, which apparently needs to be constant. Once\n> these issue resovled, do you mind fixing GStreamer code to use the\n> right one, it reads like this:\n> \n> \t\tGstMemory *mem = gst_fd_allocator_alloc(allocator, plane.fd.get(),\n> \t\t\t\t\t\t\tplane.offset + plane.length,\n> \t\t\t\t\t\t\tGST_FD_MEMORY_FLAG_DONT_CLOSE);\n> \t\tgst_memory_resize(mem, plane.offset, plane.length);\n> \n> Plane.offset is never set (always zero atm), but if its constant, its\n> the wrong one, this code should use the metadata once (the variable\n> one). You will also notice the semantic difference, we assume length\n> does not include the offset, this might need adjustment.\n\nOutside of codec drivers, data_offset is a bit of a problematic API. The\nissue with reporting a dynamic offset is that it make it impossible to\nuse fences and queue the buffer with a consumer before we know the\noffset value. The concern is of course theoretical, given that V4L2\ndoesn't have fence support, but I would really not to see widespread\ndata_offset usage before we figure this issue out.\n\nNot counting the vivid test driver and codec drivers, data_offset is\nonly used by the omap3isp driver, for entirely historical reasons (we\ndidn't know what we were doing at the time). I'd like to understand your\nuse cases better in order to determine the best way forward.\n\nNote that there is a different, and in my opinion entirely valid, use of\noffsets, which is indicating where a plane is located within a dmabuf.\nThis isn't supported by V4L2 at the moment (there are old patches on the\nlist for this, but they died out), but is I think a useful and needed\nfeature (DRM supports it). The FrameBuffer::Plane::offset field is meant\nfor this.\n\n> >  \t}\n> >  \n> >  \treturn buffer;","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 037EDC3213\n\tfor ;\n\tWed, 2 Apr 2025 00:10:09 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 84E0F68967;\n\tWed, 2 Apr 2025 02:10:08 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 0CA4B62C65\n\tfor ;\n\tWed, 2 Apr 2025 02:10:07 +0200 (CEST)","from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi\n\t[81.175.209.231])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 140D16A2;\n\tWed, 2 Apr 2025 02:08:13 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"GXIEyDN/\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1743552494;\n\tbh=QKH1nMaFzWQuqyufc7KnzcjkuWGUguExDCx4wlCJif0=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=GXIEyDN/Dm0/wDhQjRAu/jmPjPH8JT9f9s5cKww0uLVFK9aZW4zsZfGRFxhpuWvy9\n\tAjoCOUkMMMXj7nevO87r+p82va1ZLJDJUx3jHGUeoCDYZBjQZS5cKPjxmbGmhjTbD9\n\tGqdjhQJZSoUAtdNQatVcKubA8MKcGT6wJTi67+WI=","Date":"Wed, 2 Apr 2025 03:09:42 +0300","From":"Laurent Pinchart ","To":"Nicolas Dufresne ","Cc":"Paul Elder ,\n\tlibcamera-devel@lists.libcamera.org","Subject":"Re: [PATCH 2/3] libcamera: v4l2_videodevice: Report offset in\n\tdequeueBuffer","Message-ID":"<20250402000942.GA4845@pendragon.ideasonboard.com>","References":"<20250326075129.1705736-1-paul.elder@ideasonboard.com>\n\t<20250326075129.1705736-3-paul.elder@ideasonboard.com>\n\t<1de7f2b25abbc56d9792a74e0995d71937a860b6.camel@ndufresne.ca>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<1de7f2b25abbc56d9792a74e0995d71937a860b6.camel@ndufresne.ca>","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":33910,"web_url":"https://patchwork.libcamera.org/comment/33910/","msgid":"","date":"2025-04-03T16:35:43","subject":"Re: [PATCH 2/3] libcamera: v4l2_videodevice: Report offset in\n\tdequeueBuffer","submitter":{"id":17,"url":"https://patchwork.libcamera.org/api/people/17/","name":"Paul Elder","email":"paul.elder@ideasonboard.com"},"content":"On Wed, Apr 02, 2025 at 03:09:42AM +0300, Laurent Pinchart wrote:\n> On Fri, Mar 28, 2025 at 04:51:12PM -0400, Nicolas Dufresne wrote:\n> > Le mercredi 26 mars 2025 à 16:51 +0900, Paul Elder a écrit :\n> > > Fill in the offset field of the frame metadata so that it the\n> > > application can read it.\n> > > \n> > > Signed-off-by: Paul Elder \n> > > ---\n> > >  src/libcamera/v4l2_videodevice.cpp | 5 ++++-\n> > >  1 file changed, 4 insertions(+), 1 deletion(-)\n> > > \n> > > diff --git a/src/libcamera/v4l2_videodevice.cpp\n> > > b/src/libcamera/v4l2_videodevice.cpp\n> > > index f5b3fa09d9a0..5d163f7fd853 100644\n> > > --- a/src/libcamera/v4l2_videodevice.cpp\n> > > +++ b/src/libcamera/v4l2_videodevice.cpp\n> > > @@ -1957,10 +1957,13 @@ FrameBuffer *V4L2VideoDevice::dequeueBuffer()\n> > >  \t\t * The number of planes in the frame buffer and in the\n> > >  \t\t * V4L2 buffer is guaranteed to be equal at this point.\n> > >  \t\t */\n> > > -\t\tfor (unsigned int i = 0; i < numV4l2Planes; ++i)\n> > > +\t\tfor (unsigned int i = 0; i < numV4l2Planes; ++i) {\n> > >  \t\t\tmetadata.planes()[i].bytesused = planes[i].bytesused;\n> > > +\t\t\tmetadata.planes()[i].offset = planes[i].data_offset;\n> > \n> > In V4L2, data_offset is included in the total bytesused. Once you hit a\n> > non-zero offset, you will endup with byteused possibly bigger then\n> > FrameBuffer.length, which to my reading contradicts the doc.\n> > \n> > https://www.linuxtv.org/downloads/v4l-dvb-apis/userspace-api/v4l/buffer.html?highlight=data_offset#struct-v4l2-plane\n> > \n> > > +\t\t}\n> > >  \t} else {\n> > >  \t\tmetadata.planes()[0].bytesused = buf.bytesused;\n> > > +\t\tmetadata.planes()[0].offset = buf.m.offset;\n> > \n> > Should be:\n> > \n> > +\t\tmetadata.planes()[0].offset = 0;\n> > \n> > There is no support for data_offset in the original v4l2_buffer API.\n> > This offset match planes[i].mem_offset and is only useful for CPU\n> > access using mmap() and the video node FD.\n> > \n> > I think some introspection is needed, since this offset was expected to\n> > be in the framebuffer, which apparently needs to be constant. Once\n> > these issue resovled, do you mind fixing GStreamer code to use the\n> > right one, it reads like this:\n> > \n> > \t\tGstMemory *mem = gst_fd_allocator_alloc(allocator, plane.fd.get(),\n> > \t\t\t\t\t\t\tplane.offset + plane.length,\n> > \t\t\t\t\t\t\tGST_FD_MEMORY_FLAG_DONT_CLOSE);\n> > \t\tgst_memory_resize(mem, plane.offset, plane.length);\n> > \n> > Plane.offset is never set (always zero atm), but if its constant, its\n> > the wrong one, this code should use the metadata once (the variable\n> > one). You will also notice the semantic difference, we assume length\n> > does not include the offset, this might need adjustment.\n> \n> Outside of codec drivers, data_offset is a bit of a problematic API. The\n> issue with reporting a dynamic offset is that it make it impossible to\n> use fences and queue the buffer with a consumer before we know the\n> offset value. The concern is of course theoretical, given that V4L2\n> doesn't have fence support, but I would really not to see widespread\n> data_offset usage before we figure this issue out.\n\nAh ok, I see. The data is practically static but it's treated as\ndynamic. We can't expose it as static on the libcamera side either\nbecause... it's dynamic as exposed by the kernel.\n\n> Not counting the vivid test driver and codec drivers, data_offset is\n> only used by the omap3isp driver, for entirely historical reasons (we\n> didn't know what we were doing at the time). I'd like to understand your\n> use cases better in order to determine the best way forward.\n\nIt's for a client's custom platform, so I suppose I'll keep these\nout-of-tree then, since upstream support of this would need a larger\nscale kernel change.\n\n\nThanks,\n\nPaul\n\n> Note that there is a different, and in my opinion entirely valid, use of\n> offsets, which is indicating where a plane is located within a dmabuf.\n> This isn't supported by V4L2 at the moment (there are old patches on the\n> list for this, but they died out), but is I think a useful and needed\n> feature (DRM supports it). The FrameBuffer::Plane::offset field is meant\n> for this.\n> \n> > >  \t}\n> > >  \n> > >  \treturn buffer;","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id E6564C3213\n\tfor ;\n\tThu, 3 Apr 2025 16:35:54 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 4E2CE68994;\n\tThu, 3 Apr 2025 18:35:54 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id AB27568980\n\tfor ;\n\tThu, 3 Apr 2025 18:35:52 +0200 (CEST)","from pyrite.rasen.tech (unknown\n\t[IPv6:2404:7a81:160:2100:1aa1:8c68:376a:ebb6])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 96864105D;\n\tThu, 3 Apr 2025 18:33:57 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"nC12dYjB\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1743698039;\n\tbh=/+dN/5kh/3lsT56sYrURMdL8k2hVGX3buPty0u2ry4I=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=nC12dYjBaJ0RYhVsklnnRyLfItawcveiQfU8EHR6W4JRb9Bp7fw2UJKNBe3XSPlds\n\t9IN1dA13OGqWDaW1WBbZkCr4tyREXIi2d019seESWLvHrVqi/ASLnG84AGz71DbhD0\n\tPE0BfNOgvRlmNMjSMzbCnq0x0MDp1ZhjDRN2T3Es=","Date":"Fri, 4 Apr 2025 01:35:43 +0900","From":"Paul Elder ","To":"Laurent Pinchart ","Cc":"Nicolas Dufresne ,\n\tlibcamera-devel@lists.libcamera.org","Subject":"Re: [PATCH 2/3] libcamera: v4l2_videodevice: Report offset in\n\tdequeueBuffer","Message-ID":"","References":"<20250326075129.1705736-1-paul.elder@ideasonboard.com>\n\t<20250326075129.1705736-3-paul.elder@ideasonboard.com>\n\t<1de7f2b25abbc56d9792a74e0995d71937a860b6.camel@ndufresne.ca>\n\t<20250402000942.GA4845@pendragon.ideasonboard.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20250402000942.GA4845@pendragon.ideasonboard.com>","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]