[{"id":3074,"web_url":"https://patchwork.libcamera.org/comment/3074/","msgid":"<20191118192742.GI4888@pendragon.ideasonboard.com>","date":"2019-11-18T19:27:42","subject":"Re: [libcamera-devel] [RFC 07/12] libcamera: buffer: Add dedicated\n\tcontainer for buffer information","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Niklas,\n\nThank you for the patch.\n\nOn Mon, Oct 28, 2019 at 03:25:20AM +0100, Niklas Söderlund wrote:\n> The Buffer object will be split in two, one containing the memory and\n> one containing the information recorded from when the buffer is\n> dequeued. Add a container for the later in preparation for the split.\n> \n> Signed-off-by: Niklas Söderlund \n> ---\n> include/libcamera/buffer.h | 34 ++++++++++++++++++++++++++++++++++\n\nThis is missing documentation (hence the RFC status I suppose). I assume\nyou're aware of it :-)\n\n> 1 file changed, 34 insertions(+)\n> \n> diff --git a/include/libcamera/buffer.h b/include/libcamera/buffer.h\n> index 54c757ef7db8b5f6..c626f669040b3c04 100644\n> --- a/include/libcamera/buffer.h\n> +++ b/include/libcamera/buffer.h\n> @@ -105,6 +105,40 @@ private:\n> \tStream *stream_;\n> };\n> \n> +class BufferInfo\n\nAn alternative name could be BufferMetaData. I wanted to mention it as\nthat's what I envisioned when we discussed this topic a few weeks ago.\nWe need a really good naming scheme for the buffer-related API, and\nBufferInfo may be best, let's see how it fits in the big picture.\n\n> +{\n> +public:\n> +\tenum Status {\n> +\t\tBufferSuccess,\n> +\t\tBufferError,\n> +\t\tBufferCancelled,\n> +\t};\n> +\n> +\tstruct PlaneInfo {\n> +\t\tunsigned int bytesused;\n> +\t};\n\nDo you foresee more plane-specific fields in the future, or should be\ndrop this structures and replace planes_ with a vector of bytesused ? I\nthink I'm leaning a bit towards keeping it as-is, but I may change my\nmind while reviewing the rest of the series.\n\n> +\n> +\tBufferInfo(Status status, unsigned int sequence, uint64_t timestamp,\n> +\t\t const std::vector &planes)\n> +\t\t: status_(status), sequence_(sequence), timestamp_(timestamp),\n> +\t\t planes_(planes)\n> +\t{\n> +\t}\n> +\n> +\tStatus status() const { return status_; }\n> +\tunsigned int sequence() const { return sequence_; }\n> +\tunsigned int timestamp() const { return timestamp_; }\n\nThe return type doesn't match the timestamp_ member type.\n\n> +\n> +\tunsigned int planes() const { return planes_.size(); }\n> +\tconst PlaneInfo &plane(unsigned int plane) const { return planes_.at(plane); }\n\nHow about replacing those two methods with\n\n\tconst std::vector &planes() const { return planes_; }\n\n? The planes() method above is a bit ill-named, as it returns the number\nof planes, and I think returning the vector will result in more flexible\ncode for the caller.\n\n> +\n> +private:\n> +\tStatus status_;\n> +\tunsigned int sequence_;\n> +\tuint64_t timestamp_;\n\nShould this be a std::chrono type instead ?\n\n> +\tstd::vector planes_;\n> +};\n> +\n> } /* namespace libcamera */\n> \n> #endif /* __LIBCAMERA_BUFFER_H__ */","headers":{"Return-Path":"","Received":["from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id A76B060F1C\n\tfor ;\n\tMon, 18 Nov 2019 20:28:00 +0100 (CET)","from pendragon.ideasonboard.com (unknown [38.98.37.142])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id D208F540;\n\tMon, 18 Nov 2019 20:27:57 +0100 (CET)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1574105280;\n\tbh=uM07zAES4LctWKeBHsRBcQsLXdOm2+F29JI5sLLdDY4=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=hxLPKUJA+pcChxII00TYhPvUTisp9u1luG+/3yUC428q9sKXwLwblnDWn2/rfayOd\n\tuZkpYfANkyhm7kaL7fVVpj2kPCxU41JRXz1DJjHh7NvJAK/R97o0r7STiZhPOFV9vi\n\tGZv1dlErshPSBx5QIG1OHyceSMuPRFR1JxbftaKo=","Date":"Mon, 18 Nov 2019 21:27:42 +0200","From":"Laurent Pinchart ","To":"Niklas =?utf-8?q?S=C3=B6derlund?= ","Cc":"libcamera-devel@lists.libcamera.org","Message-ID":"<20191118192742.GI4888@pendragon.ideasonboard.com>","References":"<20191028022525.796995-1-niklas.soderlund@ragnatech.se>\n\t<20191028022525.796995-8-niklas.soderlund@ragnatech.se>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20191028022525.796995-8-niklas.soderlund@ragnatech.se>","User-Agent":"Mutt/1.10.1 (2018-07-13)","Subject":"Re: [libcamera-devel] [RFC 07/12] libcamera: buffer: Add dedicated\n\tcontainer for buffer information","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","X-List-Received-Date":"Mon, 18 Nov 2019 19:28:00 -0000"}},{"id":3121,"web_url":"https://patchwork.libcamera.org/comment/3121/","msgid":"<20191121004142.GB10793@bigcity.dyn.berto.se>","date":"2019-11-21T00:41:42","subject":"Re: [libcamera-devel] [RFC 07/12] libcamera: buffer: Add dedicated\n\tcontainer for buffer information","submitter":{"id":5,"url":"https://patchwork.libcamera.org/api/people/5/","name":"Niklas Söderlund","email":"niklas.soderlund@ragnatech.se"},"content":"Hi Laurent,\n\nThanks for your feedback.\n\nOn 2019-11-18 21:27:42 +0200, Laurent Pinchart wrote:\n> Hi Niklas,\n> \n> Thank you for the patch.\n> \n> On Mon, Oct 28, 2019 at 03:25:20AM +0100, Niklas Söderlund wrote:\n> > The Buffer object will be split in two, one containing the memory and\n> > one containing the information recorded from when the buffer is\n> > dequeued. Add a container for the later in preparation for the split.\n> > \n> > Signed-off-by: Niklas Söderlund \n> > ---\n> > include/libcamera/buffer.h | 34 ++++++++++++++++++++++++++++++++++\n> \n> This is missing documentation (hence the RFC status I suppose). I assume\n> you're aware of it :-)\n\n:-)\n\n> \n> > 1 file changed, 34 insertions(+)\n> > \n> > diff --git a/include/libcamera/buffer.h b/include/libcamera/buffer.h\n> > index 54c757ef7db8b5f6..c626f669040b3c04 100644\n> > --- a/include/libcamera/buffer.h\n> > +++ b/include/libcamera/buffer.h\n> > @@ -105,6 +105,40 @@ private:\n> > \tStream *stream_;\n> > };\n> > \n> > +class BufferInfo\n> \n> An alternative name could be BufferMetaData. I wanted to mention it as\n> that's what I envisioned when we discussed this topic a few weeks ago.\n> We need a really good naming scheme for the buffer-related API, and\n> BufferInfo may be best, let's see how it fits in the big picture.\n\nI'm not opposed to naming this BufferMetaData. But will keep it as \nBufferInfo until we make a decision based on the big picture.\n\n> \n> > +{\n> > +public:\n> > +\tenum Status {\n> > +\t\tBufferSuccess,\n> > +\t\tBufferError,\n> > +\t\tBufferCancelled,\n> > +\t};\n> > +\n> > +\tstruct PlaneInfo {\n> > +\t\tunsigned int bytesused;\n> > +\t};\n> \n> Do you foresee more plane-specific fields in the future, or should be\n> drop this structures and replace planes_ with a vector of bytesused ? I\n> think I'm leaning a bit towards keeping it as-is, but I may change my\n> mind while reviewing the rest of the series.\n> \n> > +\n> > +\tBufferInfo(Status status, unsigned int sequence, uint64_t timestamp,\n> > +\t\t const std::vector &planes)\n> > +\t\t: status_(status), sequence_(sequence), timestamp_(timestamp),\n> > +\t\t planes_(planes)\n> > +\t{\n> > +\t}\n> > +\n> > +\tStatus status() const { return status_; }\n> > +\tunsigned int sequence() const { return sequence_; }\n> > +\tunsigned int timestamp() const { return timestamp_; }\n> \n> The return type doesn't match the timestamp_ member type.\n\nThanks.\n\n> \n> > +\n> > +\tunsigned int planes() const { return planes_.size(); }\n> > +\tconst PlaneInfo &plane(unsigned int plane) const { return planes_.at(plane); }\n> \n> How about replacing those two methods with\n> \n> \tconst std::vector &planes() const { return planes_; }\n> \n> ? The planes() method above is a bit ill-named, as it returns the number\n> of planes, and I think returning the vector will result in more flexible\n> code for the caller.\n\nI like it will do so in next version.\n\n\n> \n> > +\n> > +private:\n> > +\tStatus status_;\n> > +\tunsigned int sequence_;\n> > +\tuint64_t timestamp_;\n> \n> Should this be a std::chrono type instead ?\n\nI'm not opposed to this, but maybe we can do this on top if we think \nit's the right thing? I have added this to my list of buffer stuff to \ndo.\n\n> \n> > +\tstd::vector planes_;\n> > +};\n> > +\n> > } /* namespace libcamera */\n> > \n> > #endif /* __LIBCAMERA_BUFFER_H__ */\n> \n> -- \n> Regards,\n> \n> Laurent Pinchart","headers":{"Return-Path":"","Received":["from mail-lj1-x235.google.com (mail-lj1-x235.google.com\n\t[IPv6:2a00:1450:4864:20::235])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id B897A60BEA\n\tfor ;\n\tThu, 21 Nov 2019 01:41:44 +0100 (CET)","by mail-lj1-x235.google.com with SMTP id p18so1187617ljc.6\n\tfor ;\n\tWed, 20 Nov 2019 16:41:44 -0800 (PST)","from localhost (h-93-159.A463.priv.bahnhof.se. [46.59.93.159])\n\tby smtp.gmail.com with ESMTPSA id\n\tg14sm316546lfj.17.2019.11.20.16.41.42\n\t(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n\tWed, 20 Nov 2019 16:41:42 -0800 (PST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ragnatech-se.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:content-transfer-encoding:in-reply-to\n\t:user-agent; bh=MNvzK82jR82KkLf/2+Qvo4+8sHl0iaqMSIduq67bP0U=;\n\tb=jH8arXbYa94Vejy0wdJf1JdHYXQR4vujPvGD0Qai6zxy6o5zVO6KNh83BO0c7fR9Aq\n\t5flxAqVISA0DMYY5rwrSl56ZXS110GYXXCrKN02CKqSvmc0kO5ohtGm1F3F4H1+eMwvf\n\tsHIvaesTQWWeUtK1noNv3us7yOduCJfMb/19nGcp27csLwV2c97rEhrJMv5hYHZ1/1RH\n\tuUo00jqBrrZzYVunDdKV1bRjB0clNTUSz1Olsr9PTxZ/Y0qU6MNtTQjE5OGvAGF0Brom\n\tjcq7OXk92m50VfUnzpK/F9AVgCjNaWcYlH5khidL+ugroFduARtNQnKcRO4oH44GpEsO\n\tsZBg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:content-transfer-encoding\n\t:in-reply-to:user-agent;\n\tbh=MNvzK82jR82KkLf/2+Qvo4+8sHl0iaqMSIduq67bP0U=;\n\tb=UqzEwe1pRm1TnLNDIDko50eft70aet4H7ScxhI40lZV5X5GFQlRBHajVp0ExuaTB9J\n\tLg3HdKnSknBx38VoTuO51eGTUu82IOrbT5XWhUQ5q1edqj8d3Scn+FWG7bh07BwpusG8\n\tb2ZMFCYj4bPKHLxNfjpeHRIET9wcvsM22XDjeTUspFoLJ+j6ddQrNzihKHBQ92dQ9Y3a\n\tT4JtHfB9by+IWwCiPTS6Nw+TnbgszE4qAVIJGIAQS/lgCzDMXyfU3pLuTFjsEDCj4cOA\n\thOI8TuBiKMLlkwDhsMMeP2WGUqx7bHCtcMOZ/v9Lq2CiIbh7rNIalnMxYDYRRUgSBQzp\n\tri5g==","X-Gm-Message-State":"APjAAAV4vgZplqU/oMshxABPGwxW2JoxhybKs2AFz7og9l6Yk05riUOW\n\t4KlSJfzOIzNgsvwp29xqpTF9qQ==","X-Google-Smtp-Source":"APXvYqxkMOdCsFzve4Ghpyc47f/+pEcXSSkNC7ZG3cejRr8hbW4zH6O4myWTk29NEEM8lRV5lntR6w==","X-Received":"by 2002:a2e:5cc6:: with SMTP id\n\tq189mr5039962ljb.160.1574296903688; \n\tWed, 20 Nov 2019 16:41:43 -0800 (PST)","Date":"Thu, 21 Nov 2019 01:41:42 +0100","From":"Niklas =?iso-8859-1?q?S=F6derlund?= ","To":"Laurent Pinchart ","Cc":"libcamera-devel@lists.libcamera.org","Message-ID":"<20191121004142.GB10793@bigcity.dyn.berto.se>","References":"<20191028022525.796995-1-niklas.soderlund@ragnatech.se>\n\t<20191028022525.796995-8-niklas.soderlund@ragnatech.se>\n\t<20191118192742.GI4888@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":"<20191118192742.GI4888@pendragon.ideasonboard.com>","User-Agent":"Mutt/1.12.1 (2019-06-15)","Subject":"Re: [libcamera-devel] [RFC 07/12] libcamera: buffer: Add dedicated\n\tcontainer for buffer information","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","X-List-Received-Date":"Thu, 21 Nov 2019 00:41:44 -0000"}}]